From netconf-bounces@ietf.org Fri Jul 4 02:07:53 2008 Return-Path: X-Original-To: netconf-archive@lists.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 CB3DA3A6B14; Fri, 4 Jul 2008 02:07:53 -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 C738B3A6B14 for ; Fri, 4 Jul 2008 02:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 To+nJ4pTXZs0 for ; Fri, 4 Jul 2008 02:07:52 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8165B3A6B0D for ; Fri, 4 Jul 2008 02:07:51 -0700 (PDT) Received: (qmail 91723 invoked from network); 4 Jul 2008 09:07:58 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jul 2008 09:07:58 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 4 Jul 2008 11:08:04 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] We need to prepare for the NETCONF Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, we are happy to get the Notification draft through the IESG. Now it's in the hands of the RFC editor. Anyway, we still have three chartered WG items running and they are available for your review: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02 http://tools.ietf.org/html/draft-ietf-netconf-tls-03 As you know, NETCONF WG session at IETF 72 is currently scheduled for Thuesday at 18:50-19:50. We would like to encourage everybody on the NETCONF mailing list to READ AND REVIEW the document updates and send their review comments and requests to the mailing list. The issue discussion is definitely needed before the WG session and is the only way to get the issues solved and the documents stable. As usual the WG session time is PRIMARILY for the discussion of ISSUES, which we couldn't solve on the maillist. Authors: Please bring not-solved issues into the session discussion. Thank you all for your support. Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 4 02:07:53 2008 Return-Path: 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 CB3DA3A6B14; Fri, 4 Jul 2008 02:07:53 -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 C738B3A6B14 for ; Fri, 4 Jul 2008 02:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 To+nJ4pTXZs0 for ; Fri, 4 Jul 2008 02:07:52 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8165B3A6B0D for ; Fri, 4 Jul 2008 02:07:51 -0700 (PDT) Received: (qmail 91723 invoked from network); 4 Jul 2008 09:07:58 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jul 2008 09:07:58 -0000 From: "Bert Wijnen - IETF" To: "Netconf" Date: Fri, 4 Jul 2008 11:08:04 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: [Netconf] We need to prepare for the NETCONF Session at IETF 72 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi All, we are happy to get the Notification draft through the IESG. Now it's in the hands of the RFC editor. Anyway, we still have three chartered WG items running and they are available for your review: http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02 http://tools.ietf.org/html/draft-ietf-netconf-tls-03 As you know, NETCONF WG session at IETF 72 is currently scheduled for Thuesday at 18:50-19:50. We would like to encourage everybody on the NETCONF mailing list to READ AND REVIEW the document updates and send their review comments and requests to the mailing list. The issue discussion is definitely needed before the WG session and is the only way to get the issues solved and the documents stable. As usual the WG session time is PRIMARILY for the discussion of ISSUES, which we couldn't solve on the maillist. Authors: Please bring not-solved issues into the session discussion. Thank you all for your support. Bert & Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 4 02:21:49 2008 Return-Path: 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 3AD1A3A6B46; Fri, 4 Jul 2008 02:21:49 -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 2FCBE3A6B46 for ; Fri, 4 Jul 2008 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] 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 EADbpYP0eCfR for ; Fri, 4 Jul 2008 02:21:47 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id EBE1B3A6B0D for ; Fri, 4 Jul 2008 02:21:46 -0700 (PDT) Received: (qmail 8360 invoked from network); 4 Jul 2008 09:21:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jul 2008 09:21:54 -0000 From: "Bert Wijnen - IETF" To: "netconf mailing list" Date: Fri, 4 Jul 2008 11:22:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Importance: Normal Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications'toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am back from vacation now (en I ENjoied it a lot; 2-3 weeks of bicycling (modest distances, like less than 50km a day with timely stops for a yellowish juice or red wine.) and relaxing). Anyway... this posting is to thank you all for your efforts on the notifications draft and to congratulate the WG for the fact that we have passed IESG approval. Special thanks to the authors/editors (Sharon and Hector). Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Ersue, Mehmet (NSN - DE/Muenich) > Verzonden: woensdag 25 juni 2008 17:33 > Aan: netconf mailing list > Onderwerp: Re: [Netconf] Protocol Action: 'NETCONF Event > Notifications'toProposed Standard > > > > I think special thanks go to the editors and the former > WG chairs, who did a tremendous work. > > BTW: Not to forget the document shepherd joining his > vacation currently. > > Cheers, > Mehmet > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 4 02:21:49 2008 Return-Path: X-Original-To: netconf-archive@lists.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 3AD1A3A6B46; Fri, 4 Jul 2008 02:21:49 -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 2FCBE3A6B46 for ; Fri, 4 Jul 2008 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] 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 EADbpYP0eCfR for ; Fri, 4 Jul 2008 02:21:47 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id EBE1B3A6B0D for ; Fri, 4 Jul 2008 02:21:46 -0700 (PDT) Received: (qmail 8360 invoked from network); 4 Jul 2008 09:21:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 4 Jul 2008 09:21:54 -0000 From: "Bert Wijnen - IETF" To: "netconf mailing list" Date: Fri, 4 Jul 2008 11:22:00 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Importance: Normal Subject: Re: [Netconf] Protocol Action: 'NETCONF Event Notifications'toProposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I am back from vacation now (en I ENjoied it a lot; 2-3 weeks of bicycling (modest distances, like less than 50km a day with timely stops for a yellowish juice or red wine.) and relaxing). Anyway... this posting is to thank you all for your efforts on the notifications draft and to congratulate the WG for the fact that we have passed IESG approval. Special thanks to the authors/editors (Sharon and Hector). Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Ersue, Mehmet (NSN - DE/Muenich) > Verzonden: woensdag 25 juni 2008 17:33 > Aan: netconf mailing list > Onderwerp: Re: [Netconf] Protocol Action: 'NETCONF Event > Notifications'toProposed Standard > > > > I think special thanks go to the editors and the former > WG chairs, who did a tremendous work. > > BTW: Not to forget the document shepherd joining his > vacation currently. > > Cheers, > Mehmet > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jul 7 14:09:44 2008 Return-Path: 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 02D3E28C241; Mon, 7 Jul 2008 14:09:44 -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 A678128C241 for ; Mon, 7 Jul 2008 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8EeFXDW6SxEP for ; Mon, 7 Jul 2008 14:09:41 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 909CE28C23B for ; Mon, 7 Jul 2008 14:09:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m67L9kR29001 for ; Mon, 7 Jul 2008 21:09:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E075.BF56E33F" Date: Mon, 7 Jul 2008 17:09:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACasw From: "Sharon Chisholm" To: Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi The following draft defines standard content for NETCONF Notifications, with an aim to support full-lifecycle configuration management. This work was deferred from the original NETCONF Notification protocol work because of the separation of protocol and content and was brought up at the mike (by someone other then the authors) at the last IETF meeting as a gap in our NETCONF solution. We would like to discuss this work at the upcoming meeting in Dublin. Sharon -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Notification Content Author(s) : S. Chisholm, et al. Filename : draft-chisholm-netconf-not-content-00.txt Pages : 29 Date : 2008-07-07 The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information that shouFrom netconf-bounces@ietf.org Mon Jul 7 14:09:44 2008 Return-Path: X-Original-To: netconf-archive@lists.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 02D3E28C241; Mon, 7 Jul 2008 14:09:44 -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 A678128C241 for ; Mon, 7 Jul 2008 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8EeFXDW6SxEP for ; Mon, 7 Jul 2008 14:09:41 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 909CE28C23B for ; Mon, 7 Jul 2008 14:09:41 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m67L9kR29001 for ; Mon, 7 Jul 2008 21:09:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E075.BF56E33F" Date: Mon, 7 Jul 2008 17:09:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACasw From: "Sharon Chisholm" To: Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi The following draft defines standard content for NETCONF Notifications, with an aim to support full-lifecycle configuration management. This work was deferred from the original NETCONF Notification protocol work because of the separation of protocol and content and was brought up at the mike (by someone other then the authors) at the last IETF meeting as a gap in our NETCONF solution. We would like to discuss this work at the upcoming meeting in Dublin. Sharon -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Notification Content Author(s) : S. Chisholm, et al. Filename : draft-chisholm-netconf-not-content-00.txt Pages : 29 Date : 2008-07-07 The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information thald be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: application/octet-stream; name="draft-chisholm-netconf-not-content-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-chisholm-netconf-not-content-00.URL Content-Disposition: attachment; filename="draft-chisholm-netconf-not-content-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLW5vdC1jb250ZW50LTAwLnR4dA0K ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; name="ATT2645947.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2645947.txt Content-Disposition: attachment; filename="ATT2645947.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8E075.BF56E33F-- t should be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: application/octet-stream; name="draft-chisholm-netconf-not-content-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-chisholm-netconf-not-content-00.URL Content-Disposition: attachment; filename="draft-chisholm-netconf-not-content-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1jaGlzaG9sbS1uZXRjb25mLW5vdC1jb250ZW50LTAwLnR4dA0K ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; name="ATT2645947.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2645947.txt Content-Disposition: attachment; filename="ATT2645947.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8E075.BF56E33F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8E075.BF56E33F-- From netconf-bounces@ietf.org Wed Jul 9 06:49:22 2008 Return-Path: X-Original-To: netconf-archive@lists.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 0A36A28C13F; Wed, 9 Jul 2008 06:49:22 -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 7D03D28C123 for ; Wed, 9 Jul 2008 06:49:21 -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=[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 zMS+nYWnPl1I for ; Wed, 9 Jul 2008 06:49:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 084A028C141 for ; Wed, 9 Jul 2008 06:49:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m69DnSPL012410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 15:49:29 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m69DnRFE014558; Wed, 9 Jul 2008 15:49:28 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 15:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 15:49:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for the IETF #72 NETCONF Session Thread-Index: Acjhuf/QXxkZOGOIQlCyUbt9UTuHWgAD+cVg From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 09 Jul 2008 13:49:27.0934 (UTC) FILETIME=[9AF351E0:01C8E1CA] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16020.007 X-TM-AS-Result: No--24.566300-8.000000-31 Subject: [Netconf] Agenda for the IETF #72 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930240100==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0930240100== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E1CA.9A6F115B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E1CA.9A6F115B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Dear NETCONF WG, >=20 > below is the draft agenda for the NETCONF WG session=20 > at the IETF #72. If you feel that some topic is missing, pls=20 > let us know asap. >=20 > Our main focus in the session will be on open issue=20 > discussion. However, until now there was not much=20 > discussion in the list except the TLS draft. >=20 > Please let us also know whether you have any concrete=20 > topic for the open mic session. >=20 > We need to organize (as always) the scribes and minute=20 > From netconf-bounces@ietf.org Wed Jul 9 06:49:22 2008 Return-Path: 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 0A36A28C13F; Wed, 9 Jul 2008 06:49:22 -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 7D03D28C123 for ; Wed, 9 Jul 2008 06:49:21 -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=[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 zMS+nYWnPl1I for ; Wed, 9 Jul 2008 06:49:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 084A028C141 for ; Wed, 9 Jul 2008 06:49:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m69DnSPL012410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 15:49:29 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m69DnRFE014558; Wed, 9 Jul 2008 15:49:28 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 15:49:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 15:49:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for the IETF #72 NETCONF Session Thread-Index: Acjhuf/QXxkZOGOIQlCyUbt9UTuHWgAD+cVg From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 09 Jul 2008 13:49:27.0934 (UTC) FILETIME=[9AF351E0:01C8E1CA] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16020.007 X-TM-AS-Result: No--24.566300-8.000000-31 Subject: [Netconf] Agenda for the IETF #72 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0930240100==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0930240100== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E1CA.9A6F115B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E1CA.9A6F115B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Dear NETCONF WG, >=20 > below is the draft agenda for the NETCONF WG session=20 > at the IETF #72. If you feel that some topic is missing, pls=20 > let us know asap. >=20 > Our main focus in the session will be on open issue=20 > discussion. However, until now there was not much=20 > discussion in the list except the TLS draft. >=20 > Please let us also know whether you have any concrete=20 > topic for the open mic session. >=20 > We need to organize (as always) the scribes and minute=20 > takerstakers before the meeting. Volunteers are appreciated. >=20 > Bert & Mehmet >=20 > ------------------------------------------------------- > NETCONF WG=20 > IETF 72, Dublin, Ireland=20 >=20 > TUESDAY, July 29, 2008 1850-1950=20 >=20 > WG Chairs:=20 > Bert Wijnen =20 > Mehmet Ersue =20 >=20 > Scribes,=20 > Agenda bashing,=20 > WG status review (5 minutes)=20 >=20 > Current charter items:=20 >=20 > 1. Netconf monitoring (15 minutes)=20 > Marc Scott=20 > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 >=20 > =20 > 2. Fine-grained locking (15 minutes)=20 > Balazs Lengyel=20 > =20 > http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02=20 >=20 > 3. NETCONF over TLS (15 minutes)=20 > Mohamad Badra=20 > http://tools.ietf.org/html/draft-ietf-netconf-tls-03=20 >=20 > Not-chartered document: (5 minutes)=20 > NETCONF Notification Content=20 > Sharon Chisholm=20 > =20 > AOB=20 >=20 > Open mic (5 minutes)=20 > Hot topics to discuss?=20 >=20 ------_=_NextPart_001_01C8E1CA.9A6F115B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for the IETF #72 NETCONF Session

Dear NETCONF = WG,

below is the draft agenda for the NETCONF WG session
at the IETF #72. If you feel that some topic is missing, pls
let us know asap.

Our main focus in the session will be on open issue
discussion. However, until now there was not much
discussion in the list except the TLS draft.

Please let us also know whether you have any concrete
topic for the open mic session.

We need to organize (as always) the scribes and minute
takers before the meeting. Volunteers are appreciated.

Bert & Mehmet

-------------------------------------------------------
NETCONF WG =
IETF 72, = Dublin, Ireland

TUESDAY, July = 29, 2008 1850-1950

  WG = Chairs:
  Bert = Wijnen <bertietf@bwijnen.net>
  Mehmet = Ersue <mehmet.ersue@nsn.com>

  Scribes, =
  Agenda = bashing,
  WG = status review (5 minutes)

   = Current charter items:

       1. Netconf = monitoring (15 minutes)
         &n= bsp; Marc Scott
         &n= bsp; http://tools.ietf.org/html/draft-ietf-netconf-monitoring= -02=20 > Bert & Mehmet >=20 > ------------------------------------------------------- > NETCONF WG=20 > IETF 72, Dublin, Ireland=20 >=20 > TUESDAY, July 29, 2008 1850-1950=20 >=20 > WG Chairs:=20 > Bert Wijnen =20 > Mehmet Ersue =20 >=20 > Scribes,=20 > Agenda bashing,=20 > WG status review (5 minutes)=20 >=20 > Current charter items:=20 >=20 > 1. Netconf monitoring (15 minutes)=20 > Marc Scott=20 > http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 >=20 > =20 > 2. Fine-grained locking (15 minutes)=20 > Balazs Lengyel=20 > =20 > http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02=20 >=20 > 3. NETCONF over TLS (15 minutes)=20 > Mohamad Badra=20 > http://tools.ietf.org/html/draft-ietf-netconf-tls-03=20 >=20 > Not-chartered document: (5 minutes)=20 > NETCONF Notification Content=20 > Sharon Chisholm=20 > =20 > AOB=20 >=20 > Open mic (5 minutes)=20 > Hot topics to discuss?=20 >=20 ------_=_NextPart_001_01C8E1CA.9A6F115B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for the IETF #72 NETCONF Session

Dear NETCONF = WG,

below is the draft agenda for the NETCONF WG session
at the IETF #72. If you feel that some topic is missing, pls
let us know asap.

Our main focus in the session will be on open issue
discussion. However, until now there was not much
discussion in the list except the TLS draft.

Please let us also know whether you have any concrete
topic for the open mic session.

We need to organize (as always) the scribes and minute
takers before the meeting. Volunteers are appreciated.

Bert & Mehmet

-------------------------------------------------------
NETCONF WG =
IETF 72, = Dublin, Ireland

TUESDAY, July = 29, 2008 1850-1950

  WG = Chairs:
  Bert = Wijnen <bertietf@bwijnen.net>
  Mehmet = Ersue <mehmet.ersue@nsn.com>

  Scribes, =
  Agenda = bashing,
  WG = status review (5 minutes)

   = Current charter items:

       1. Netconf = monitoring (15 minutes)
         &n= bsp; Marc Scott
         &n= bsp; http://tools.ietf.org/html/draft-ietf-netconf-monitoring= -02
   =
       2. Fine-grained = locking (15 minutes)
         &n= bsp; Balazs Lengyel
         &n= bsp; http://tools.ietf.org/html/draft-ietf-netconf-partial-lo= ck-02

        3. NETCONF = over TLS (15 minutes)
         &n= bsp;  Mohamad Badra
         &n= bsp;  http://tools.ietf.org/html/draft-ietf-netconf-tls-03 =

   = Not-chartered document: (5 minutes)
      NETCONF Notification = Content
      Sharon Chisholm =
     
   AOB =

  Open mic (5 = minutes)
      Hot topics to discuss? =

------_=_NextPart_001_01C8E1CA.9A6F115B-- --===============0930240100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0930240100==-- T SIZE=3D2 FACE=3D"Verdana">
   =
       2. Fine-grained = locking (15 minutes)
         &n= bsp; Balazs Lengyel
         &n= bsp; http://tools.ietf.org/html/draft-ietf-netconf-partial-lo= ck-02

        3. NETCONF = over TLS (15 minutes)
         &n= bsp;  Mohamad Badra
         &n= bsp;  http://tools.ietf.org/html/draft-ietf-netconf-tls-03 =

   = Not-chartered document: (5 minutes)
      NETCONF Notification = Content
      Sharon Chisholm =
     
   AOB =

  Open mic (5 = minutes)
      Hot topics to discuss? =

------_=_NextPart_001_01C8E1CA.9A6F115B-- --===============0930240100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0930240100==-- From netconf-bounces@ietf.org Wed Jul 9 07:24:28 2008 Return-Path: X-Original-To: netconf-archive@lists.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 2A2143A68E8; Wed, 9 Jul 2008 07:24:28 -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 E31273A6897 for ; Wed, 9 Jul 2008 07:24:26 -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=[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 mVI5AvVmEL3j for ; Wed, 9 Jul 2008 07:24:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 873F33A68E8 for ; Wed, 9 Jul 2008 07:24:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m69EOXp0002279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 16:24:33 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m69EOVPP015435; Wed, 9 Jul 2008 16:24:33 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 16:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E1CF.8095BED3" Date: Wed, 9 Jul 2008 16:24:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Agenda for the IETF #72 NETCONF Session Thread-Index: Acjhuf/QXxkZOGOIQlCyUbt9UTuHWgAD+cVgAADgYQA= From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 09 Jul 2008 14:24:31.0914 (UTC) FILETIME=[810530A0:01C8E1CF] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16020.007 X-TM-AS-Result: No--18.256000-8.000000-31 Subject: [Netconf] Updated Agenda for the IETF #72 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8E1CF.8095BED3" ------_=_NextPart_002_01C8E1CF.8095BED3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I updated the agenda with the URL of the Notification content=20 draft. Please read and comment it. =20 Please feel free to indicate if something is missing in the agenda. =20 Mehmet=20 =20 -------------------------------------------------------=20 =20 NETCONF WG=20 IETF 72, Dublin, Ireland=20 TUESDAY, July 29, 2008 1850-1950=20 WG Chairs:=20 Bert Wijnen =20 Mehmet Ersue =20 Scribes,=20 Agenda bashing,=20 WG status review (5 minutes)=20 Current charter items:=20 1. Netconf monitoring (15 minutes)=20 Mark Scott=20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 =20 =20 2. Fine-grained locking (15 minutes)=20 Balazs Lengyel=20 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02 =20 3. NETCONF over TLS (15 minutes)=20 Mohamad Badra=20 http://tools.ietf.org/html/draft-ietf-netconf-tls-03 =20 Not-chartered document: (5 minutes)=20 NETCONF Notification Content=20 Sharon Chisholm=20 http://tools.ietf.org/html/draft-chisholm-netconf-not-content-00=20 =20 AOB=20 Open mic (5 minutes)=20 Hot topics to discuss?=20 ------_=_NextPart_002_01C8E1CF.8095BED3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for the IETF #72 NETCONF Session
Hi=20 All,
 
I updated the agenda with the URL of the Notification content =
draft. Please read and comment it.
 
Please=20 feel free to indicate if something is missing in=20 the agenda.
 
Mehmet 
 
-----------------------------= -------------------------- 
 
 NETCONF WG =
IETF 72, Dublin, Ireland=20

TUESDAY, July 29, 2008 1850-1950

  WG Chairs:
  Bert Wijnen <bertietf@bwijnen.net> =
  Mehmet Ersue=20 <mehmet.ersue@nsn.com>

  Scribes,
  Agenda bashing,
  WG status review (5 minutes) =

   Current charter items:

       1. Netconf monitoring (15 = minutes)=20
           = Mark Scott
          =20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02=20
  =20
       2. Fine-grained locking = (15 minutes)=20
           = Balazs=20 Lengyel
          =20 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02

        3. NETCONF over TLS = (15=20 minutes)
          &nbs= p;=20 Mohamad Badra
          &nbs= p;=20 http://tools.ietf.org/html/draft-ietf-netconf-tls-03<= /SPAN>

   Not-chartered document: (5 minutes) =
      = NETCONF=20 Notification Content
      Sharon Chisholm 
    =20  http://tools.ietf.org/html/draft-chisholm-netconf-not-content-00 
      
   AOB

  Open mic (5 minutes)
      Hot topics to = discuss?=20

------_=_NextPart_002_01C8E1CF.8095BED3-- ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: text/plain; name="ATT524510.txt" Content-Transfer-Encoding: base64 Content-Description: ATT524510.txt Content-Disposition: inline; filename="ATT524510.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8E1CF.8095BED3-- From netconf-bounces@ietf.org Wed Jul 9 07:24:28 2008 Return-Path: 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 2A2143A68E8; Wed, 9 Jul 2008 07:24:28 -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 E31273A6897 for ; Wed, 9 Jul 2008 07:24:26 -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=[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 mVI5AvVmEL3j for ; Wed, 9 Jul 2008 07:24:26 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 873F33A68E8 for ; Wed, 9 Jul 2008 07:24:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m69EOXp0002279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2008 16:24:33 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m69EOVPP015435; Wed, 9 Jul 2008 16:24:33 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 16:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8E1CF.8095BED3" Date: Wed, 9 Jul 2008 16:24:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Agenda for the IETF #72 NETCONF Session Thread-Index: Acjhuf/QXxkZOGOIQlCyUbt9UTuHWgAD+cVgAADgYQA= From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "netconf mailing list" X-OriginalArrivalTime: 09 Jul 2008 14:24:31.0914 (UTC) FILETIME=[810530A0:01C8E1CF] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16020.007 X-TM-AS-Result: No--18.256000-8.000000-31 Subject: [Netconf] Updated Agenda for the IETF #72 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C8E1CF.8095BED3" ------_=_NextPart_002_01C8E1CF.8095BED3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I updated the agenda with the URL of the Notification content=20 draft. Please read and comment it. =20 Please feel free to indicate if something is missing in the agenda. =20 Mehmet=20 =20 -------------------------------------------------------=20 =20 NETCONF WG=20 IETF 72, Dublin, Ireland=20 TUESDAY, July 29, 2008 1850-1950=20 WG Chairs:=20 Bert Wijnen =20 Mehmet Ersue =20 Scribes,=20 Agenda bashing,=20 WG status review (5 minutes)=20 Current charter items:=20 1. Netconf monitoring (15 minutes)=20 Mark Scott=20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02 =20 =20 2. Fine-grained locking (15 minutes)=20 Balazs Lengyel=20 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02 =20 3. NETCONF over TLS (15 minutes)=20 Mohamad Badra=20 http://tools.ietf.org/html/draft-ietf-netconf-tls-03 =20 Not-chartered document: (5 minutes)=20 NETCONF Notification Content=20 Sharon Chisholm=20 http://tools.ietf.org/html/draft-chisholm-netconf-not-content-00=20 =20 AOB=20 Open mic (5 minutes)=20 Hot topics to discuss?=20 ------_=_NextPart_002_01C8E1CF.8095BED3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda for the IETF #72 NETCONF Session
Hi=20 All,
 
I updated the agenda with the URL of the Notification content =
draft. Please read and comment it.
 
Please=20 feel free to indicate if something is missing in=20 the agenda.
 
Mehmet 
 
-----------------------------= -------------------------- 
 
 NETCONF WG =
IETF 72, Dublin, Ireland=20

TUESDAY, July 29, 2008 1850-1950

  WG Chairs:
  Bert Wijnen <bertietf@bwijnen.net> =
  Mehmet Ersue=20 <mehmet.ersue@nsn.com>

  Scribes,
  Agenda bashing,
  WG status review (5 minutes) =

   Current charter items:

       1. Netconf monitoring (15 = minutes)=20
           = Mark Scott
          =20 http://tools.ietf.org/html/draft-ietf-netconf-monitoring-02=20
  =20
       2. Fine-grained locking = (15 minutes)=20
           = Balazs=20 Lengyel
          =20 http://tools.ietf.org/html/draft-ietf-netconf-partial-lock-02

        3. NETCONF over TLS = (15=20 minutes)
          &nbs= p;=20 Mohamad Badra
          &nbs= p;=20 http://tools.ietf.org/html/draft-ietf-netconf-tls-03<= /SPAN>

   Not-chartered document: (5 minutes) =
      = NETCONF=20 Notification Content
      Sharon Chisholm 
    =20  http://tools.ietf.org/html/draft-chisholm-netconf-not-content-00 
      
   AOB

  Open mic (5 minutes)
      Hot topics to = discuss?=20

------_=_NextPart_002_01C8E1CF.8095BED3-- ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: text/plain; name="ATT524510.txt" Content-Transfer-Encoding: base64 Content-Description: ATT524510.txt Content-Disposition: inline; filename="ATT524510.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== ------_=_NextPart_001_01C8E1CF.8095BED3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8E1CF.8095BED3-- From netconf-bounces@ietf.org Thu Jul 10 06:53:22 2008 Return-Path: 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 E610F28C0DD; Thu, 10 Jul 2008 06:53:22 -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 464493A6A10 for ; Thu, 10 Jul 2008 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 a46AAI-nsBtL for ; Thu, 10 Jul 2008 06:53:20 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 304813A6A16 for ; Thu, 10 Jul 2008 06:53:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6ADrVi16780 for ; Thu, 10 Jul 2008 13:53:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:51:56 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKw References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi For some internal stuff I need clarification on the first point. As such, I propose that the given list of statistics be clarified to just be for NETCONF. This would not preclude adding additional statistics in the future that go beyond this (current number of sessions for example might include CLI sessions). Please let me know if this is not a reasonable approach. Thanks, Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Thursday, June 26, 2008 2:41 PM To: netconf@ietf.org Subject: [Netconf] Comments on Monitoring Draft Hi 1. If the statistics are limited to NETCONF traffic, this should be clarified in the description clauses. Since we discuss CLI sessions in another part of the data model, this is not completely obvious. 2. For consistency with other NETCONF specifications, the protocol operation definition should be broken out separately from the content definition. 3. Should any of the parameters to the verb be optional? Currently they are all mandatory. If my device only has XSDs, do I really have to specify this parameter every single time? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/From netconf-bounces@ietf.org Thu Jul 10 06:53:22 2008 Return-Path: X-Original-To: netconf-archive@lists.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 E610F28C0DD; Thu, 10 Jul 2008 06:53:22 -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 464493A6A10 for ; Thu, 10 Jul 2008 06:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 a46AAI-nsBtL for ; Thu, 10 Jul 2008 06:53:20 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 304813A6A16 for ; Thu, 10 Jul 2008 06:53:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6ADrVi16780 for ; Thu, 10 Jul 2008 13:53:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 09:51:56 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKw References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi For some internal stuff I need clarification on the first point. As such, I propose that the given list of statistics be clarified to just be for NETCONF. This would not preclude adding additional statistics in the future that go beyond this (current number of sessions for example might include CLI sessions). Please let me know if this is not a reasonable approach. Thanks, Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Thursday, June 26, 2008 2:41 PM To: netconf@ietf.org Subject: [Netconf] Comments on Monitoring Draft Hi 1. If the statistics are limited to NETCONF traffic, this should be clarified in the description clauses. Since we discuss CLI sessions in another part of the data model, this is not completely obvious. 2. For consistency with other NETCONF specifications, the protocol operation definition should be broken out separately from the content definition. 3. Should any of the parameters to the verb be optional? Currently they are all mandatory. If my device only has XSDs, do I really have to specify this parameter every single time? Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/lisnetconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf tinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 10 07:19:34 2008 Return-Path: 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 178883A6A2C; Thu, 10 Jul 2008 07:19:34 -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 42F643A6960 for ; Thu, 10 Jul 2008 07:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 UK0wZD5CqXjq for ; Thu, 10 Jul 2008 07:19:32 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C53723A6912 for ; Thu, 10 Jul 2008 07:19:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,338,1212379200"; d="scan'208";a="134899580" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 10 Jul 2008 10:19:45 -0400 X-IronPort-AV: E=Sophos;i="4.30,338,1212379200"; d="scan'208";a="226389627" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jul 2008 10:19:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 16:19:43 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKwAAEGdkA= References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org All this looks reasonable to me. And all this stuff is useful. Dan (contributor opinion) > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, July 10, 2008 4:52 PM > To: netconf@ietf.org > Subject: Re: [Netconf] Comments on Monitoring Draft > > Hi > > For some internal stuff I need clarification on the first > point. As such, I propose that the given list of statistics > be clarified to just be for NETCONF. This would not preclude > adding additional statistics in the future that go beyond > this (current number of sessions for example might include > CLI sessions). > > Please let me know if this is not a reasonable approach. > > Thanks, > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, > Sharon (CAR:ZZ00) > Sent: Thursday, June 26, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Monitoring Draft > > Hi > > 1. If the statistics are limited to NETCONF traffic, this > should be clarified in the description clauses. Since we > discuss CLI sessions in another part of the data model, this > is not completely obvious. > > 2. For consistency with other NETCONF specifications, the > protocol operation definition should be broken out separately > from the content definition. > > 3. Should any of the parameters to the verb be optional? > Currently they are all mandatory. If my device only has XSDs, > do I really have to specify this parameter every single time? > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 10 07:19:34 2008 Return-Path: X-Original-To: netconf-archive@lists.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 178883A6A2C; Thu, 10 Jul 2008 07:19:34 -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 42F643A6960 for ; Thu, 10 Jul 2008 07:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 UK0wZD5CqXjq for ; Thu, 10 Jul 2008 07:19:32 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C53723A6912 for ; Thu, 10 Jul 2008 07:19:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,338,1212379200"; d="scan'208";a="134899580" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 10 Jul 2008 10:19:45 -0400 X-IronPort-AV: E=Sophos;i="4.30,338,1212379200"; d="scan'208";a="226389627" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jul 2008 10:19:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Jul 2008 16:19:43 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKwAAEGdkA= References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org All this looks reasonable to me. And all this stuff is useful. Dan (contributor opinion) > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, July 10, 2008 4:52 PM > To: netconf@ietf.org > Subject: Re: [Netconf] Comments on Monitoring Draft > > Hi > > For some internal stuff I need clarification on the first > point. As such, I propose that the given list of statistics > be clarified to just be for NETCONF. This would not preclude > adding additional statistics in the future that go beyond > this (current number of sessions for example might include > CLI sessions). > > Please let me know if this is not a reasonable approach. > > Thanks, > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, > Sharon (CAR:ZZ00) > Sent: Thursday, June 26, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Monitoring Draft > > Hi > > 1. If the statistics are limited to NETCONF traffic, this > should be clarified in the description clauses. Since we > discuss CLI sessions in another part of the data model, this > is not completely obvious. > > 2. For consistency with other NETCONF specifications, the > protocol operation definition should be broken out separately > from the content definition. > > 3. Should any of the parameters to the verb be optional? > Currently they are all mandatory. If my device only has XSDs, > do I really have to specify this parameter every single time? > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 17 09:34:21 2008 Return-Path: X-Original-To: netconf-archive@lists.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 C4ABE3A6AAB; Thu, 17 Jul 2008 09:34:21 -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 847CB3A6AAB for ; Thu, 17 Jul 2008 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NUgJpsiabldz for ; Thu, 17 Jul 2008 09:34:19 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 6BC3F3A6AA7 for ; Thu, 17 Jul 2008 09:34:19 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6HGYl129366 for ; Thu, 17 Jul 2008 16:34:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 12:34:40 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB1304D579@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKwAAEGdkABYre2wA== References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> From: "Mark Scott" To: "Sharon Chisholm" , Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, Points 1 and 2 can be updated in next version. On Point 3 my preference would be to keep the 'format' parameter mandatory. My thinking here: It encourages a manager to specifically request the format of interest. I also think it helps to simplify cases like this: - device has only one format for a specific schema - likely rare but each schema may not be the same format - manager can send without 'format' parameter - device returns whatever format it has for that identifier and version - manager has to either cross-check the schema-list entry or the result contents to confirm the format - later, a new instance of same schema (in another format) is added - manager still sends without 'format', would we expect: A) to return an error indicating format not specified? Effectively making the parm mandatory B) return a 'default format'? In which case would be need to define and advertise the default format? However, this won't work in cases where a device doesn't have a schema in the default format; unless the device enforced the presence of at least the default format but that's putting too many resFrom netconf-bounces@ietf.org Thu Jul 17 09:34:21 2008 Return-Path: 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 C4ABE3A6AAB; Thu, 17 Jul 2008 09:34:21 -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 847CB3A6AAB for ; Thu, 17 Jul 2008 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 NUgJpsiabldz for ; Thu, 17 Jul 2008 09:34:19 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 6BC3F3A6AA7 for ; Thu, 17 Jul 2008 09:34:19 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6HGYl129366 for ; Thu, 17 Jul 2008 16:34:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Jul 2008 12:34:40 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB1304D579@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Comments on Monitoring Draft Thread-Index: AcjXvDUnAlzSayBCSNWKgcgVm0Zo1gK15UKwAAEGdkABYre2wA== References: <713043CE8B8E1348AF3C546DBE02C1B4153961FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415642CDE@zcarhxm2.corp.nortel.com> From: "Mark Scott" To: "Sharon Chisholm" , Subject: Re: [Netconf] Comments on Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, Points 1 and 2 can be updated in next version. On Point 3 my preference would be to keep the 'format' parameter mandatory. My thinking here: It encourages a manager to specifically request the format of interest. I also think it helps to simplify cases like this: - device has only one format for a specific schema - likely rare but each schema may not be the same format - manager can send without 'format' parameter - device returns whatever format it has for that identifier and version - manager has to either cross-check the schema-list entry or the result contents to confirm the format - later, a new instance of same schema (in another format) is added - manager still sends without 'format', would we expect: A) to return an error indicating format not specified? Effectively making the parm mandatory B) return a 'default format'? In which case would be need to define and advertise the default format? However, this won't work in cases where a device doesn't have a schema in the default format; unless the device enforced the presence of at least the default format but that's putting too many restrictitrictions on the device in my opinion So I'd like to just keep it simple with the mandatory parameter. I'm open to discussion though. thx, Mark > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, July 10, 2008 4:52 PM > To: netconf@ietf.org > Subject: Re: [Netconf] Comments on Monitoring Draft > > Hi > > For some internal stuff I need clarification on the first point. As > such, I propose that the given list of statistics be clarified to just > be for NETCONF. This would not preclude adding additional statistics > in the future that go beyond this (current number of sessions for > example might include CLI sessions). > > Please let me know if this is not a reasonable approach. > > Thanks, > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon > (CAR:ZZ00) > Sent: Thursday, June 26, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Monitoring Draft > > Hi > > 1. If the statistics are limited to NETCONF traffic, this should be > clarified in the description clauses. Since we discuss CLI sessions in > another part of the data model, this is not completely obvious. > > 2. For consistency with other NETCONF specifications, the protocol > operation definition should be broken out separately from the content > definition. > > 3. Should any of the parameters to the verb be optional? > Currently they are all mandatory. If my device only has XSDs, do I > really have to specify this parameter every single time? > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 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 ons on the device in my opinion So I'd like to just keep it simple with the mandatory parameter. I'm open to discussion though. thx, Mark > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Sharon Chisholm > Sent: Thursday, July 10, 2008 4:52 PM > To: netconf@ietf.org > Subject: Re: [Netconf] Comments on Monitoring Draft > > Hi > > For some internal stuff I need clarification on the first point. As > such, I propose that the given list of statistics be clarified to just > be for NETCONF. This would not preclude adding additional statistics > in the future that go beyond this (current number of sessions for > example might include CLI sessions). > > Please let me know if this is not a reasonable approach. > > Thanks, > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon > (CAR:ZZ00) > Sent: Thursday, June 26, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Comments on Monitoring Draft > > Hi > > 1. If the statistics are limited to NETCONF traffic, this should be > clarified in the description clauses. Since we discuss CLI sessions in > another part of the data model, this is not completely obvious. > > 2. For consistency with other NETCONF specifications, the protocol > operation definition should be broken out separately from the content > definition. > > 3. Should any of the parameters to the verb be optional? > Currently they are all mandatory. If my device only has XSDs, do I > really have to specify this parameter every single time? > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 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 From netconf-bounces@ietf.org Sat Jul 19 08:02:22 2008 Return-Path: X-Original-To: netconf-archive@lists.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 B6B543A691A; Sat, 19 Jul 2008 08:02:22 -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 433683A696C; Fri, 18 Jul 2008 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.077 X-Spam-Level: X-Spam-Status: No, score=-17.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 t6p7YaEzYHsp; Fri, 18 Jul 2008 16:39:26 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 8E4C63A6954; Fri, 18 Jul 2008 16:39:26 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 152CE1443E6; Fri, 18 Jul 2008 16:40:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080718234001.152CE1443E6@bosco.isi.edu> Date: Fri, 18 Jul 2008 16:40:01 -0700 (PDT) X-Mailman-Approved-At: Sat, 19 Jul 2008 08:02:21 -0700 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5277 Title: NETCONF Event Notifications Author: S. Chisholm, H. Trevino Status: Standards Track Date: July 2008 Mailbox: schishol@nortel.com, htrevino@cisco.com Pages: 35 Characters: 70878 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-notification-14.txt URL: http://www.rfc-editor.org/rfc/rfc5277.txt This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the From netconf-bounces@ietf.org Sat Jul 19 08:02:22 2008 Return-Path: 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 B6B543A691A; Sat, 19 Jul 2008 08:02:22 -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 433683A696C; Fri, 18 Jul 2008 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.077 X-Spam-Level: X-Spam-Status: No, score=-17.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 t6p7YaEzYHsp; Fri, 18 Jul 2008 16:39:26 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 8E4C63A6954; Fri, 18 Jul 2008 16:39:26 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 152CE1443E6; Fri, 18 Jul 2008 16:40:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080718234001.152CE1443E6@bosco.isi.edu> Date: Fri, 18 Jul 2008 16:40:01 -0700 (PDT) X-Mailman-Approved-At: Sat, 19 Jul 2008 08:02:21 -0700 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5277 Title: NETCONF Event Notifications Author: S. Chisholm, H. Trevino Status: Standards Track Date: July 2008 Mailbox: schishol@nortel.com, htrevino@cisco.com Pages: 35 Characters: 70878 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-notification-14.txt URL: http://www.rfc-editor.org/rfc/rfc5277.txt This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol (NETCONF). This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. [STANDARDS TRACK] This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jul 19 08:15:28 2008 Return-Path: X-Original-To: netconf-archive@lists.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 D41753A69B2; Sat, 19 Jul 2008 08:15:28 -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 621FC3A69B2 for ; Sat, 19 Jul 2008 08:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, STOX_REPLY_TYPE=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 LmqDMC8dkOMQ for ; Sat, 19 Jul 2008 08:15:26 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 356013A6952 for ; Sat, 19 Jul 2008 08:15:26 -0700 (PDT) Received: (qmail 46279 invoked from network); 19 Jul 2008 15:16:01 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 19 Jul 2008 15:16:01 -0000 Message-ID: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: Date: Sat, 19 Jul 2008 17:15:36 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Subject: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Congrats to the WG and specifically to the authors/editors. Also extra thanks to Mehmet who did the shepherding work while I was absent on email last week. Bert Wijnen Document shepherd and co-chair for the Netconf WG. ----- Original Message ----- From: To: ; Cc: ; Sent: Saturday, July 19, 2008 1:40 AM Subject: [Netconf] RFC 5277 on NETCONF Event Notifications > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5277 > > Title: NETCONF Event Notifications > Author: S. Chisholm, H. Trevino > Status: Standards Track > Date: July 2008 > Mailbox: schishol@nortel.com, > htrevino@cisco.com > Pages: 35 > Characters: 70878 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-notification-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc5277.txt > > This document defines mechanisms that provide an asynchronous message > notification delivery service for the Network Configuration protocol > (NETCONF). This is an optional capability built on top of the base > NETCONF definition. This document defines the capabilities and > operations necessary to support this service. [STANDARDS TRACK] > > This document is a product of the Network Configuration Working Group of > the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > 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 From netconf-bounces@ietf.org Sat Jul 19 08:15:28 2008 Return-Path: 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 D41753A69B2; Sat, 19 Jul 2008 08:15:28 -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 621FC3A69B2 for ; Sat, 19 Jul 2008 08:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, STOX_REPLY_TYPE=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 LmqDMC8dkOMQ for ; Sat, 19 Jul 2008 08:15:26 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 356013A6952 for ; Sat, 19 Jul 2008 08:15:26 -0700 (PDT) Received: (qmail 46279 invoked from network); 19 Jul 2008 15:16:01 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 19 Jul 2008 15:16:01 -0000 Message-ID: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: Date: Sat, 19 Jul 2008 17:15:36 +0200 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Subject: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Congrats to the WG and specifically to the authors/editors. Also extra thanks to Mehmet who did the shepherding work while I was absent on email last week. Bert Wijnen Document shepherd and co-chair for the Netconf WG. ----- Original Message ----- From: To: ; Cc: ; Sent: Saturday, July 19, 2008 1:40 AM Subject: [Netconf] RFC 5277 on NETCONF Event Notifications > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5277 > > Title: NETCONF Event Notifications > Author: S. Chisholm, H. Trevino > Status: Standards Track > Date: July 2008 > Mailbox: schishol@nortel.com, > htrevino@cisco.com > Pages: 35 > Characters: 70878 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-notification-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc5277.txt > > This document defines mechanisms that provide an asynchronous message > notification delivery service for the Network Configuration protocol > (NETCONF). This is an optional capability built on top of the base > NETCONF definition. This document defines the capabilities and > operations necessary to support this service. [STANDARDS TRACK] > > This document is a product of the Network Configuration Working Group of > the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see > http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > 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 From netconf-bounces@ietf.org Sun Jul 20 03:34:51 2008 Return-Path: X-Original-To: netconf-archive@lists.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 90A783A69D9; Sun, 20 Jul 2008 03:34:51 -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 2A7463A69D9 for ; Sun, 20 Jul 2008 03:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 EAQCMtMVUsJF for ; Sun, 20 Jul 2008 03:34:50 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0EA6D3A69C3 for ; Sun, 20 Jul 2008 03:34:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,218,1215403200"; d="scan'208";a="136125883" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 20 Jul 2008 06:35:26 -0400 X-IronPort-AV: E=Sophos;i="4.31,218,1215403200"; d="scan'208";a="238817494" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Jul 2008 06:35:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 20 Jul 2008 12:35:22 +0200 Message-ID: In-Reply-To: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications Thread-Index: Acjpsl5J3CR9BtMVQ1+sDwa2in1EpQAoWOcg References: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Subject: Re: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am joining my congratulations to those from Bert and thanks to all editors and contributors in the WG. With this we have fully completed the first charter of NETCONF. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Saturday, July 19, 2008 6:16 PM > To: netconf@ietf.org > Subject: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications > > Congrats to the WG and specifically to the authors/editors. > > Also extra thanks to Mehmet who did the shepherding work > while I was absent on email last week. > > Bert Wijnen > Document shepherd and co-chair for the Netconf WG. > > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Saturday, July 19, 2008 1:40 AM > Subject: [Netconf] RFC 5277 on NETCONF Event Notifications > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 5277 > > > > Title: NETCONF Event Notifications > > Author: S. Chisholm, H. Trevino > > Status: Standards Track > > Date: July 2008 > > Mailbox: schishol@nortel.com, > > htrevino@cisco.com > > Pages: 35 > > Characters: 70878 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-netconf-notification-14.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc5277.txt > > > > This document defines mechanisms that provide an > asynchronous message > > notification delivery service for the Network Configuration protocol > > (NETCONF). This is an optional capability built on top of the base > > NETCONF definition. This document defines the capabilities and > > operations necessary to support this service. [STANDARDS TRACK] > > > > This document is a product of the Network Configuration > Working Group of > > the IETF. > > > > This is now a Proposed Standard Protocol. > > > > STANDARDS TRACK: This document specifies an Internet standards track > > protocol for the Internet community,and requests discussion and > > suggestions > > for improvements. Please refer to the current edition of > the Internet > > Official Protocol Standards (STD 1) for the standardization > state and > > status of this protocol. Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see > > http://www.rfc-editor.org/rfcsearch.html. > > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to > rfc-editor@rfc-editor.org. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > > > > > The RFC Editor Team > > USC/Information Sciences Institute > > > > > > _______________________________________________ > > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jul 20 03:34:51 2008 Return-Path: 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 90A783A69D9; Sun, 20 Jul 2008 03:34:51 -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 2A7463A69D9 for ; Sun, 20 Jul 2008 03:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] 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 EAQCMtMVUsJF for ; Sun, 20 Jul 2008 03:34:50 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 0EA6D3A69C3 for ; Sun, 20 Jul 2008 03:34:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,218,1215403200"; d="scan'208";a="136125883" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 20 Jul 2008 06:35:26 -0400 X-IronPort-AV: E=Sophos;i="4.31,218,1215403200"; d="scan'208";a="238817494" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Jul 2008 06:35:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 20 Jul 2008 12:35:22 +0200 Message-ID: In-Reply-To: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications Thread-Index: Acjpsl5J3CR9BtMVQ1+sDwa2in1EpQAoWOcg References: <98533D69944F40A5A152FB57A4CDC62A@BertLaptop> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Subject: Re: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I am joining my congratulations to those from Bert and thanks to all editors and contributors in the WG. With this we have fully completed the first charter of NETCONF. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Saturday, July 19, 2008 6:16 PM > To: netconf@ietf.org > Subject: [Netconf] Fw: RFC 5277 on NETCONF Event Notifications > > Congrats to the WG and specifically to the authors/editors. > > Also extra thanks to Mehmet who did the shepherding work > while I was absent on email last week. > > Bert Wijnen > Document shepherd and co-chair for the Netconf WG. > > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Saturday, July 19, 2008 1:40 AM > Subject: [Netconf] RFC 5277 on NETCONF Event Notifications > > > > > > A new Request for Comments is now available in online RFC libraries. > > > > > > RFC 5277 > > > > Title: NETCONF Event Notifications > > Author: S. Chisholm, H. Trevino > > Status: Standards Track > > Date: July 2008 > > Mailbox: schishol@nortel.com, > > htrevino@cisco.com > > Pages: 35 > > Characters: 70878 > > Updates/Obsoletes/SeeAlso: None > > > > I-D Tag: draft-ietf-netconf-notification-14.txt > > > > URL: http://www.rfc-editor.org/rfc/rfc5277.txt > > > > This document defines mechanisms that provide an > asynchronous message > > notification delivery service for the Network Configuration protocol > > (NETCONF). This is an optional capability built on top of the base > > NETCONF definition. This document defines the capabilities and > > operations necessary to support this service. [STANDARDS TRACK] > > > > This document is a product of the Network Configuration > Working Group of > > the IETF. > > > > This is now a Proposed Standard Protocol. > > > > STANDARDS TRACK: This document specifies an Internet standards track > > protocol for the Internet community,and requests discussion and > > suggestions > > for improvements. Please refer to the current edition of > the Internet > > Official Protocol Standards (STD 1) for the standardization > state and > > status of this protocol. Distribution of this memo is unlimited. > > > > This announcement is sent to the IETF-Announce and rfc-dist lists. > > To subscribe or unsubscribe, see > > http://www.ietf.org/mailman/listinfo/ietf-announce > > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > > > For searching the RFC series, see > > http://www.rfc-editor.org/rfcsearch.html. > > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > > > Requests for special distribution should be addressed to either the > > author of the RFC in question, or to > rfc-editor@rfc-editor.org. Unless > > specifically noted otherwise on the RFC itself, all RFCs are for > > unlimited distribution. > > > > > > The RFC Editor Team > > USC/Information Sciences Institute > > > > > > _______________________________________________ > > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jul 21 01:11:12 2008 Return-Path: X-Original-To: netconf-archive@lists.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 946363A6804; Mon, 21 Jul 2008 01:11:12 -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 CEE403A6804 for ; Mon, 21 Jul 2008 01:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bpx-HE26r8qj for ; Mon, 21 Jul 2008 01:11:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 89DF93A6774 for ; Mon, 21 Jul 2008 01:11:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8Bjj0029083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 10:11:45 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8Bjqh030759; Mon, 21 Jul 2008 10:11:45 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 10:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 10:11:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjrCWrf22XotsfZTqeCi4yQt6ScVg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "Mark Scott" , "Sharon Chisholm" , "Martin Bjorklund" X-OriginalArrivalTime: 21 Jul 2008 08:11:46.0082 (UTC) FILETIME=[6AE71020:01C8EB09] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.005 X-TM-AS-Result: No--17.256700-8.000000-31 Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928299060==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1928299060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB09.6A7A7353" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB09.6A7A7353 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Sharon, Martin, I reviewed the draft NETCONF Monitoring Schema.=20 Please find my comments below.=20 General comments:=20 - I was wondering whether the WG finds it useful if the title of the=20 draft reflects also the second topic covered in the document,=20 e.g. "NETCONF Monitoring and Schema Retrieval". - Since thisFrom netconf-bounces@ietf.org Mon Jul 21 01:11:12 2008 Return-Path: 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 946363A6804; Mon, 21 Jul 2008 01:11:12 -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 CEE403A6804 for ; Mon, 21 Jul 2008 01:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bpx-HE26r8qj for ; Mon, 21 Jul 2008 01:11:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 89DF93A6774 for ; Mon, 21 Jul 2008 01:11:09 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8Bjj0029083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 10:11:45 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8Bjqh030759; Mon, 21 Jul 2008 10:11:45 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 10:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 10:11:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjrCWrf22XotsfZTqeCi4yQt6ScVg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "Mark Scott" , "Sharon Chisholm" , "Martin Bjorklund" X-OriginalArrivalTime: 21 Jul 2008 08:11:46.0082 (UTC) FILETIME=[6AE71020:01C8EB09] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.005 X-TM-AS-Result: No--17.256700-8.000000-31 Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928299060==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1928299060== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB09.6A7A7353" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB09.6A7A7353 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Sharon, Martin, I reviewed the draft NETCONF Monitoring Schema.=20 Please find my comments below.=20 General comments:=20 - I was wondering whether the WG finds it useful if the title of the=20 draft reflects also the second topic covered in the document,=20 e.g. "NETCONF Monitoring and Schema Retrieval". - Since this is a is a standard track document we should use the RFC 2116=20 terminology and state whether a Schema element MUST or SHOULD be=20 used. I could only find in two cases the explanation that an element is=20 "optional". - Since we are going to register the XML Schema at IANA I agree that=20 the schema needs to be self-explaining. For a consistent specification=20 we need also to define the schema elements in the document sufficiently. - I did not check the YANG module. I think Martin or other YANG men=20 can do this better than me. Comments per chapter: 1. Introduction The text in the introduction is redundant with the text in Abstract.=20 I would like to suggest to write here a bit more in detail why we need=20 Netconf protocol monitoring and Netconf schema retrieval. It should=20 be made clear why this standard document is important and needed. 1.1. Definition of Terms We should add the terms "Global Lock" and "Partial Lock" to the terminology=20 list.=20 2. XML Schema to Monitor NETCONF I would change the first sentence for more clearness. I am not sure=20 whether we are "proposing to allow...". IMO we are standardizing the=20 data which MUST be used by a NETCONF client to monitor . . . 2.1.1. capabilities - In chapter 2.1. and 2.1.5. the types of the schema elements have=20 been specified. I would suggest to do this also in chapters 2.1.1.,=20 2.1.3., 2.1.4., and 2.1.6.. - I don't understand "Minimally"? I would rather delete this word and=20 re-formulate more clearly. - Please state here that this element is a mandatory list and at least=20 one capability MUST be given. - IANA does not support the use of a URL to IANA registry in standard=20 documents. Please refer to the URN by its name or better list the capabilities=20 defined in the capability URN. 2.1.2. configurations - I would suggest to define here also the types "GlobalLock" and "PartialLock"=20 by their name. - Description of the element lockId is missing. - The element lockedNodes of the type PartialLock has been defined in the=20 XML Schema as an optional list. IMO if a partial lock exists then at least one=20 lockedNodes element should be available.=20 - I think we should use "MUST" instead of "will" if we think it has to be used. - Please state that the element "locks" is optional. 2.1.3. schemas - The schema location is defined in the XML Schema as a non-mandatory=20 list. This does not fit to the description in 2.1.3.. I think location should=20 be a mandatory element, or? - I would delete the statement on RPC in 2.1.3. and add=20 in chapter "3.1 New NETCONF RPC, " that get-schema is=20 using the same elements as defined in chapter 2.1.3. The chapter 3.1.=20 should be self-explaining and include all necessary information. 2.1.4. sessions s/Idenfities transport/Identifies transport/ 2.1.5. subscriptions - s/List of notifications subscriptions/List of notification subscriptions/ - Please use RFC 2116 terminology to indicate that sessionId MUST=20 have the same value as returned in 'sessions' to allow correlation. 3.1. New NETCONF RPC, - I would like to suggest to use the same RPC definition format as=20 it has been used in NETCONF protocol and Notification standard=20 documents with following parts. Description: Parameters: Response: Example: - The description in the last paragraph in 3.1. focuses on schema=20 list retrieval and is redundant with chapter 3.2. I would suggest to put this text into the chapter 3.2. 3.2. NETCONF Schema List Retrieval ( monitoring data) - Last sentence of this chapter is misleading (". . . using the=20 RPC described _later_ in this draft."). Please refer=20 to the chapter where is defined by its number,=20 e.g. ". . . is defined in chapter 3.1 ". - Please give a reference to chapter 7.7. in the NETCONF=20 protocol where the protocol operation is defined. 5.1. NETCONF Monitoring Schema s/RPC definition: <get-schema>/RPC definition: / 6. Security Considerations I wostandard track document we should use the RFC 2116=20 terminology and state whether a Schema element MUST or SHOULD be=20 used. I could only find in two cases the explanation that an element is=20 "optional". - Since we are going to register the XML Schema at IANA I agree that=20 the schema needs to be self-explaining. For a consistent specification=20 we need also to define the schema elements in the document sufficiently. - I did not check the YANG module. I think Martin or other YANG men=20 can do this better than me. Comments per chapter: 1. Introduction The text in the introduction is redundant with the text in Abstract.=20 I would like to suggest to write here a bit more in detail why we need=20 Netconf protocol monitoring and Netconf schema retrieval. It should=20 be made clear why this standard document is important and needed. 1.1. Definition of Terms We should add the terms "Global Lock" and "Partial Lock" to the terminology=20 list.=20 2. XML Schema to Monitor NETCONF I would change the first sentence for more clearness. I am not sure=20 whether we are "proposing to allow...". IMO we are standardizing the=20 data which MUST be used by a NETCONF client to monitor . . . 2.1.1. capabilities - In chapter 2.1. and 2.1.5. the types of the schema elements have=20 been specified. I would suggest to do this also in chapters 2.1.1.,=20 2.1.3., 2.1.4., and 2.1.6.. - I don't understand "Minimally"? I would rather delete this word and=20 re-formulate more clearly. - Please state here that this element is a mandatory list and at least=20 one capability MUST be given. - IANA does not support the use of a URL to IANA registry in standard=20 documents. Please refer to the URN by its name or better list the capabilities=20 defined in the capability URN. 2.1.2. configurations - I would suggest to define here also the types "GlobalLock" and "PartialLock"=20 by their name. - Description of the element lockId is missing. - The element lockedNodes of the type PartialLock has been defined in the=20 XML Schema as an optional list. IMO if a partial lock exists then at least one=20 lockedNodes element should be available.=20 - I think we should use "MUST" instead of "will" if we think it has to be used. - Please state that the element "locks" is optional. 2.1.3. schemas - The schema location is defined in the XML Schema as a non-mandatory=20 list. This does not fit to the description in 2.1.3.. I think location should=20 be a mandatory element, or? - I would delete the statement on RPC in 2.1.3. and add=20 in chapter "3.1 New NETCONF RPC, " that get-schema is=20 using the same elements as defined in chapter 2.1.3. The chapter 3.1.=20 should be self-explaining and include all necessary information. 2.1.4. sessions s/Idenfities transport/Identifies transport/ 2.1.5. subscriptions - s/List of notifications subscriptions/List of notification subscriptions/ - Please use RFC 2116 terminology to indicate that sessionId MUST=20 have the same value as returned in 'sessions' to allow correlation. 3.1. New NETCONF RPC, - I would like to suggest to use the same RPC definition format as=20 it has been used in NETCONF protocol and Notification standard=20 documents with following parts. Description: Parameters: Response: Example: - The description in the last paragraph in 3.1. focuses on schema=20 list retrieval and is redundant with chapter 3.2. I would suggest to put this text into the chapter 3.2. 3.2. NETCONF Schema List Retrieval ( monitoring data) - Last sentence of this chapter is misleading (". . . using the=20 RPC described _later_ in this draft."). Please refer=20 to the chapter where is defined by its number,=20 e.g. ". . . is defined in chapter 3.1 ". - Please give a reference to chapter 7.7. in the NETCONF=20 protocol where the protocol operation is defined. 5.1. NETCONF Monitoring Schema s/RPC definition: <get-schema>/RPC definition: / 6. Security Considerations I would chuld change the text: "The information in this Schema provides=20 information about . . . " to "The NETCONF monitoring schema as defined in this document provides=20 information about . . ."=20 8. Normative References Please add draft-ietf-netconf-partial-lock- to the list of informative references. X. IANA Considerations I guess we will ask IANA to register the monitoring schema defined in=20 chapter 5.1.. Therefor we need also an IANA considerations chapter.=20 Please see the Notifications RFC 5277 chapter 8. for an example. Cheers,=20 Mehmet ------_=_NextPart_001_01C8EB09.6A7A7353 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, = Martin,

I reviewed the = draft NETCONF Monitoring Schema.
Please find my = comments below.

General comments: =

- I was wondering = whether the WG finds it useful if the title of the
draft reflects = also the second topic covered in the document,
e.g. "NETCONF = Monitoring and Schema Retrieval".

- Since this is a = standard track document we should use the RFC 2116
terminology and = state whether a Schema element MUST or SHOULD be
used. I could only = find in two cases the explanation that an element is
"optional".

- Since we are = going to register the XML Schema at IANA I agree that
the schema needs = to be self-explaining. For a consistent specification
we need also to = define the schema elements in the document sufficiently.

- I did not check = the YANG module. I think Martin or other YANG men
can do this better = than me.

Comments per = chapter:

1. = Introduction

The text in the = introduction is redundant with the text in Abstract.
I would like to = suggest to write here a bit more in detail why we need
Netconf protocol = monitoring and Netconf schema retrieval. It should
be made clear why = this standard document is important and needed.

1.1. Definition of = Terms

We should add the = terms "Global Lock" and "Partial Lock" to the = terminology
Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, = Martin,

I reviewed the = draft NETCONF Monitoring Schema.
Please find my = comments below.

General comments: =

- I was wondering = whether the WG finds it useful if the title of the
draft reflects = also the second topic covered in the document,
e.g. "NETCONF = Monitoring and Schema Retrieval".

- Since this is a = standard track document we should use the RFC 2116
terminology and = state whether a Schema element MUST or SHOULD be
used. I could only = find in two cases the explanation that an element is
"optional".

- Since we are = going to register the XML Schema at IANA I agree that
the schema needs = to be self-explaining. For a consistent specification
we need also to = define the schema elements in the document sufficiently.

- I did not check = the YANG module. I think Martin or other YANG men
can do this better = than me.

Comments per = chapter:

1. = Introduction

The text in the = introduction is redundant with the text in Abstract.
I would like to = suggest to write here a bit more in detail why we need
Netconf protocol = monitoring and Netconf schema retrieval. It should
be made clear why = this standard document is important and needed.

1.1. Definition of = Terms

We should add the = terms "Global Lock" and "Partial Lock" to the = terminology
list. =

2. XML Schema to = Monitor NETCONF

I would change the = first sentence for more clearness. I am not sure
whether we are = "proposing to allow...". IMO we are standardizing the =
data which MUST be = used by a NETCONF client to monitor . . .

2.1.1. = capabilities

- In chapter 2.1. = and 2.1.5. the types of the schema elements have
been specified. I = would suggest to do this also in chapters 2.1.1.,
2.1.3., 2.1.4., = and 2.1.6..

- I don't = understand "Minimally"? I would rather delete this word and =
re-formulate more = clearly.

- Please state here = that this element is a mandatory list and at least
one capability = MUST be given.

- IANA does not = support the use of a URL to IANA registry in standard
documents. Please = refer to the URN by its name or better list the capabilities =
defined in the = capability URN.

2.1.2. = configurations

- I would suggest = to define here also the types "GlobalLock" and = "PartialLock"
by their = name.

- Description of = the element lockId is missing.

- The element = lockedNodes of the type PartialLock has been defined in the =
XML Schema as an = optional list. IMO if a partial lock exists then at least one =
lockedNodes = element should be available.

- I think we should = use "MUST" instead of "will" if we think it has to = be used.

- Please state that = the element "locks" is optional.

2.1.3. = schemas

- The schema = location is defined in the XML Schema as a non-mandatory
list. This does = not fit to the description in 2.1.3.. I think location should =
be a mandatory = element, or?

- I would delete = the statement on <get-schema> RPC in 2.1.3. and add
in chapter = "3.1 New NETCONF RPC, <get-schema>" that get-schema is =
using the same = elements as defined in chapter 2.1.3. The chapter 3.1.
should be = self-explaining and include all necessary information.

2.1.4. = sessions

s/Idenfities = transport/Identifies transport/

2.1.5. = subscriptions

- s/List of = notifications subscriptions/List of notification = subscriptions/

- Please use RFC = 2116 terminology to indicate that sessionId MUST
have the same = value as returned in 'sessions' to allow correlation.


3.1. New NETCONF = RPC, <get-schema>

- I would like to = suggest to use the same RPC definition format as
it has been used = in NETCONF protocol and Notification standard
documents with = following parts.

   = Description:
   = Parameters:
   = Response:
   = Example:

- The description = in the last paragraph in 3.1. focuses on schema
list retrieval and = is redundant with chapter 3.2. I would suggest
to put this text = into the chapter 3.2.

3.2. NETCONF Schema = List Retrieval (<get> monitoring data)

- Last sentence of = this chapter is misleading (". . . using the
<get-schema> = RPC described _later_ in this draft."). Please refer
to the chapter = where  <get-schema> is defined by its number,
e.g. ". . . = is defined in chapter 3.1 <get-schema>".

- Please give a = reference to chapter 7.7. <get> in the NETCONF
protocol where the = <get> protocol operation is defined.

5.1. NETCONF = Monitoring Schema

s/RPC = definition:  &lt;get-schema&gt;/RPC definition:  = <get-schema>/

6. Security = Considerations

I would change the = text: "The information in this Schema provides
information about = . . . " to
"The NETCONF = monitoring schema as defined in this document provides
information about = . . ."

8. Normative = References

Please add = draft-ietf-netconf-partial-lock- to the list of = informative
references.

X.  IANA = Considerations

I guess we will ask = IANA to register the monitoring schema defined in
chapter 5.1.. = Therefor we need also an IANA considerations chapter.
Please see the = Notifications RFC 5277 chapter  8. for an example.


Cheers, =
Mehmet

------_=_NextPart_001_01C8EB09.6A7A7353-- --===============1928299060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1928299060==-- >list. =

2. XML Schema to = Monitor NETCONF

I would change the = first sentence for more clearness. I am not sure
whether we are = "proposing to allow...". IMO we are standardizing the =
data which MUST be = used by a NETCONF client to monitor . . .

2.1.1. = capabilities

- In chapter 2.1. = and 2.1.5. the types of the schema elements have
been specified. I = would suggest to do this also in chapters 2.1.1.,
2.1.3., 2.1.4., = and 2.1.6..

- I don't = understand "Minimally"? I would rather delete this word and =
re-formulate more = clearly.

- Please state here = that this element is a mandatory list and at least
one capability = MUST be given.

- IANA does not = support the use of a URL to IANA registry in standard
documents. Please = refer to the URN by its name or better list the capabilities =
defined in the = capability URN.

2.1.2. = configurations

- I would suggest = to define here also the types "GlobalLock" and = "PartialLock"
by their = name.

- Description of = the element lockId is missing.

- The element = lockedNodes of the type PartialLock has been defined in the =
XML Schema as an = optional list. IMO if a partial lock exists then at least one =
lockedNodes = element should be available.

- I think we should = use "MUST" instead of "will" if we think it has to = be used.

- Please state that = the element "locks" is optional.

2.1.3. = schemas

- The schema = location is defined in the XML Schema as a non-mandatory
list. This does = not fit to the description in 2.1.3.. I think location should =
be a mandatory = element, or?

- I would delete = the statement on <get-schema> RPC in 2.1.3. and add
in chapter = "3.1 New NETCONF RPC, <get-schema>" that get-schema is =
using the same = elements as defined in chapter 2.1.3. The chapter 3.1.
should be = self-explaining and include all necessary information.

2.1.4. = sessions

s/Idenfities = transport/Identifies transport/

2.1.5. = subscriptions

- s/List of = notifications subscriptions/List of notification = subscriptions/

- Please use RFC = 2116 terminology to indicate that sessionId MUST
have the same = value as returned in 'sessions' to allow correlation.


3.1. New NETCONF = RPC, <get-schema>

- I would like to = suggest to use the same RPC definition format as
it has been used = in NETCONF protocol and Notification standard
documents with = following parts.

   = Description:
   = Parameters:
   = Response:
   = Example:

- The description = in the last paragraph in 3.1. focuses on schema
list retrieval and = is redundant with chapter 3.2. I would suggest
to put this text = into the chapter 3.2.

3.2. NETCONF Schema = List Retrieval (<get> monitoring data)

- Last sentence of = this chapter is misleading (". . . using the
<get-schema> = RPC described _later_ in this draft."). Please refer
to the chapter = where  <get-schema> is defined by its number,
e.g. ". . . = is defined in chapter 3.1 <get-schema>".

- Please give a = reference to chapter 7.7. <get> in the NETCONF
protocol where the = <get> protocol operation is defined.

5.1. NETCONF = Monitoring Schema

s/RPC = definition:  &lt;get-schema&gt;/RPC definition:  = <get-schema>/

6. Security = Considerations

I would change the = text: "The information in this Schema provides
information about = . . . " to
"The NETCONF = monitoring schema as defined in this document provides
information about = . . ."

8. Normative = References

Please add = draft-ietf-netconf-partial-lock- to the list of = informative
references.

X.  IANA = Considerations

I guess we will ask = IANA to register the monitoring schema defined in
chapter 5.1.. = Therefor we need also an IANA considerations chapter.
Please see the = Notifications RFC 5277 chapter  8. for an example.


Cheers, =
Mehmet

------_=_NextPart_001_01C8EB09.6A7A7353-- --===============1928299060== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1928299060==-- From netconf-bounces@ietf.org Mon Jul 21 01:17:14 2008 Return-Path: X-Original-To: netconf-archive@lists.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 588453A6806; Mon, 21 Jul 2008 01:17:14 -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 ADEAE3A6806 for ; Mon, 21 Jul 2008 01:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 qfy6tB4nl9YF for ; Mon, 21 Jul 2008 01:17:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C6D1D3A67F8 for ; Mon, 21 Jul 2008 01:17:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8HloR018988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 10:17:48 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8HlMR009272; Mon, 21 Jul 2008 10:17:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 10:17:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 10:17:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-partial-lock-02.txt Thread-Index: AcjrCkJYcdbCRtLSRyu2i39FBzAwNg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" , "netconf mailing list" X-OriginalArrivalTime: 21 Jul 2008 08:17:47.0830 (UTC) FILETIME=[42856D60:01C8EB0A] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.005 X-TM-AS-Result: No--8.751500-8.000000-31 Subject: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2084711940==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============2084711940== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB0A.41FB89AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB0A.41FB89AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, I reviewed the draft "Partial Lock RPC for NETCONF".=20 Please find my comments below.=20 General comments:=20 - The document looks good. Do you think we should bring it with=20 an updated version to WGLC after the IETF meeting? - Are we going to register the XML Schema at IANA as we did for=20 RFC 5277? In any case I would suggest to have the Schema as=20 self-explaining.=20 Comments per chapter: 2.1. Overview - "The system MUST ensure . . ." I don't know how to ensure this if it is a non-NETCONF management system. The statement sounds like a normative statement but it does not cover=20 any standard-relevant definition. It is actually a generic statement and I would suggest to find another formulation than "MUST". - I would split the 3rd paragraph into two sentences for more clarity: "The duration of the partial lock is defined as beginning when the partial lock is granted. The partial lock lasts until either the corresponding operation succeeds or the NETCONF session terminates." 2.2. Dependencies s/in Section 2.4.1 /in Section 2.4.1 ./ 2.4.1. - I would indicate the beginning of the description part of the =20 operation with: - I would suggest to indicate that the the "portion of the data store" is a=20 "coherent set of nodes". - 6th paragraph: "If a top level node of a locked subtree is deleted, . . ." Why is it necessary to keep the lock with a "nil scope" present? I would expect that a lock with a nil scope is not needed and should not be kept. - s/A partial lock MUST fail/A partial lock operation MUST fail/ - 2nd bullet: " o Any part of the scope to be locked is already locked . . ." I think we should have a note here to explain why we think that a partial=20 lock can be also introduced by a non-NETCONF management system and=20 how this could be realized. I agree with an earlier comment that Netconf locking (both global and partial)=20 is creating new requirements for SNMP and other protocols. I would propose=20 to explain the impact on other management protocols in this note. - s/If the select expressions return/If the select expression returns/ 2.5. Modifications to Existing Operations I would reorganize the first sentence for more clarity, e.g.: "A granted partial-lock will cause operations to fail, if it wants to modify=20 the already locked area and is executed in a NETCONF session other=20 than the one that owns the lock." 3. Security Considerations Do the two sub-paragraphs below belong into the security considerations or should they be put to the end of the paragraph 2.4.2. ? They have at least to do with releasing of locks. "The partial-lock is automatically released when . . .=20 The operation allows terminating other users . . ." 5. Appendix A - XML Schema for Partial Locking (normative) Please add the element descriptions in the YANG module also into the XML Schema as documentation to get it self-explaining. Cheers,=20 Mehmet ------_=_NextPart_001_01C8EB0A.41FB89AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-netconf-partial-lock-02.txt

Hi = Balazs,

I reviewed the = draft "Partial Lock RPC for NETCONF".
Please find my = comments below.

General comments: =

- The document = looks good. Do you think we should bring it with
an updated version = to WGLC after the IETF meeting?

- Are we going to = register the XML Schema at IANA as we did for
RFC 5277? In any = case I would suggest to have the Schema as
self-explaining. =


Comments per = chapter:

2.1. = Overview

- "The system = MUST ensure . . ."

I don't know how to = ensure this if it is a non-NETCONF management system.
The statement = sounds like a normative statement but it does not cover
any = standard-relevant definition. It is actually a generic statement and =
I would suggest to = find another formulation than "MUST".

- I would split the = 3rd paragraph into two sentences for more clarity:
"The duration = of the partial lock is defined as beginning when the
partial lock is = granted.  The partial lock lasts until either the = corresponding
<partial-unlock> operation succeeds or the = NETCONF session terminates."

2.2. = Dependencies

s/in = Section 2.4.1/in Section 2.4.1./

2.4.1. = <partial-lock>

- I would = indicate the beginning of the description part of the = <partial-lock>
operation with: = <Description:>

- I would = suggest to indicate that the the "portion of the data store" = is a
"coherent = set of nodes".

- 6th paragraph: = "If a top level node of a locked subtree is deleted, . . = ."

Why is it = necessary to keep the lock with a "nil scope" = present?
I would expect = that a lock with a nil scope is not needed and should not
be = kept.

- s/A partial = lock MUST fail/A partial lock operation MUST fail/

- 2nd bullet: = " o  Any part of the scope to be locked is already locked . . = ."

I think we = should have a note here to explain why we think that a partial =
lock can be = also introduced by a non-NETCONF management system and
how this could = be realized.
I agree with an = earlier comment that Netconf locking (both global and partial) =
is creating new = requirements for SNMP and other protocols. I would propose =
to explain the = impact on other management protocols in this note.

- s/If the = select expressions return/If the select expression = returns/


2.5. = Modifications to Existing Operations

I would = reorganize the first sentence for more clarity, e.g.:
"A granted = partial-lock will cause operations to fail, if it wants to modify =
the already = locked area and is executed in a NETCONF session other
than the one = that owns the lock."

3. Security = Considerations

Do the two = sub-paragraphs below belong into the security = considerations
or should they = be put to the end of the paragraph 2.4.2. = <partial-unlock>?
They have at = least to do with releasing of locks.

"The = partial-lock is automatically released when . . .
The = <kill-session> operation allows terminating other users . . = ."

5. Appendix A - = XML Schema for Partial Locking (normative)

Please add the = element descriptions in the YANG module also into the XML
Schema as = documentation to get it self-explaining.

Cheers,
Mehmet

------_=_NextPart_001_01C8EB0A.41FB89AD-- --===============2084711940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============2084711940==-- From netconf-bounces@ietf.org Mon Jul 21 01:17:14 2008 Return-Path: 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 588453A6806; Mon, 21 Jul 2008 01:17:14 -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 ADEAE3A6806 for ; Mon, 21 Jul 2008 01:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 qfy6tB4nl9YF for ; Mon, 21 Jul 2008 01:17:12 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id C6D1D3A67F8 for ; Mon, 21 Jul 2008 01:17:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8HloR018988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 10:17:48 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6L8HlMR009272; Mon, 21 Jul 2008 10:17:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 10:17:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 10:17:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-partial-lock-02.txt Thread-Index: AcjrCkJYcdbCRtLSRyu2i39FBzAwNg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" , "netconf mailing list" X-OriginalArrivalTime: 21 Jul 2008 08:17:47.0830 (UTC) FILETIME=[42856D60:01C8EB0A] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.005 X-TM-AS-Result: No--8.751500-8.000000-31 Subject: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2084711940==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============2084711940== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB0A.41FB89AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB0A.41FB89AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Balazs, I reviewed the draft "Partial Lock RPC for NETCONF".=20 Please find my comments below.=20 General comments:=20 - The document looks good. Do you think we should bring it with=20 an updated version to WGLC after the IETF meeting? - Are we going to register the XML Schema at IANA as we did for=20 RFC 5277? In any case I would suggest to have the Schema as=20 self-explaining.=20 Comments per chapter: 2.1. Overview - "The system MUST ensure . . ." I don't know how to ensure this if it is a non-NETCONF management system. The statement sounds like a normative statement but it does not cover=20 any standard-relevant definition. It is actually a generic statement and I would suggest to find another formulation than "MUST". - I would split the 3rd paragraph into two sentences for more clarity: "The duration of the partial lock is defined as beginning when the partial lock is granted. The partial lock lasts until either the corresponding operation succeeds or the NETCONF session terminates." 2.2. Dependencies s/in Section 2.4.1 /in Section 2.4.1 ./ 2.4.1. - I would indicate the beginning of the description part of the =20 operation with: - I would suggest to indicate that the the "portion of the data store" is a=20 "coherent set of nodes". - 6th paragraph: "If a top level node of a locked subtree is deleted, . . ." Why is it necessary to keep the lock with a "nil scope" present? I would expect that a lock with a nil scope is not needed and should not be kept. - s/A partial lock MUST fail/A partial lock operation MUST fail/ - 2nd bullet: " o Any part of the scope to be locked is already locked . . ." I think we should have a note here to explain why we think that a partial=20 lock can be also introduced by a non-NETCONF management system and=20 how this could be realized. I agree with an earlier comment that Netconf locking (both global and partial)=20 is creating new requirements for SNMP and other protocols. I would propose=20 to explain the impact on other management protocols in this note. - s/If the select expressions return/If the select expression returns/ 2.5. Modifications to Existing Operations I would reorganize the first sentence for more clarity, e.g.: "A granted partial-lock will cause operations to fail, if it wants to modify=20 the already locked area and is executed in a NETCONF session other=20 than the one that owns the lock." 3. Security Considerations Do the two sub-paragraphs below belong into the security considerations or should they be put to the end of the paragraph 2.4.2. ? They have at least to do with releasing of locks. "The partial-lock is automatically released when . . .=20 The operation allows terminating other users . . ." 5. Appendix A - XML Schema for Partial Locking (normative) Please add the element descriptions in the YANG module also into the XML Schema as documentation to get it self-explaining. Cheers,=20 Mehmet ------_=_NextPart_001_01C8EB0A.41FB89AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-netconf-partial-lock-02.txt

Hi = Balazs,

I reviewed the = draft "Partial Lock RPC for NETCONF".
Please find my = comments below.

General comments: =

- The document = looks good. Do you think we should bring it with
an updated version = to WGLC after the IETF meeting?

- Are we going to = register the XML Schema at IANA as we did for
RFC 5277? In any = case I would suggest to have the Schema as
self-explaining. =


Comments per = chapter:

2.1. = Overview

- "The system = MUST ensure . . ."

I don't know how to = ensure this if it is a non-NETCONF management system.
The statement = sounds like a normative statement but it does not cover
any = standard-relevant definition. It is actually a generic statement and =
I would suggest to = find another formulation than "MUST".

- I would split the = 3rd paragraph into two sentences for more clarity:
"The duration = of the partial lock is defined as beginning when the
partial lock is = granted.  The partial lock lasts until either the = corresponding
<partial-unlock> operation succeeds or the = NETCONF session terminates."

2.2. = Dependencies

s/in = Section 2.4.1/in Section 2.4.1./

2.4.1. = <partial-lock>

- I would = indicate the beginning of the description part of the = <partial-lock>
operation with: = <Description:>

- I would = suggest to indicate that the the "portion of the data store" = is a
"coherent = set of nodes".

- 6th paragraph: = "If a top level node of a locked subtree is deleted, . . = ."

Why is it = necessary to keep the lock with a "nil scope" = present?
I would expect = that a lock with a nil scope is not needed and should not
be = kept.

- s/A partial = lock MUST fail/A partial lock operation MUST fail/

- 2nd bullet: = " o  Any part of the scope to be locked is already locked . . = ."

I think we = should have a note here to explain why we think that a partial =
lock can be = also introduced by a non-NETCONF management system and
how this could = be realized.
I agree with an = earlier comment that Netconf locking (both global and partial) =
is creating new = requirements for SNMP and other protocols. I would propose =
to explain the = impact on other management protocols in this note.

- s/If the = select expressions return/If the select expression = returns/


2.5. = Modifications to Existing Operations

I would = reorganize the first sentence for more clarity, e.g.:
"A granted = partial-lock will cause operations to fail, if it wants to modify =
the already = locked area and is executed in a NETCONF session other
than the one = that owns the lock."

3. Security = Considerations

Do the two = sub-paragraphs below belong into the security = considerations
or should they = be put to the end of the paragraph 2.4.2. = <partial-unlock>?
They have at = least to do with releasing of locks.

"The = partial-lock is automatically released when . . .
The = <kill-session> operation allows terminating other users . . = ."

5. Appendix A - = XML Schema for Partial Locking (normative)

Please add the = element descriptions in the YANG module also into the XML
Schema as = documentation to get it self-explaining.

Cheers,
Mehmet

------_=_NextPart_001_01C8EB0A.41FB89AD-- --===============2084711940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============2084711940==-- From netconf-bounces@ietf.org Tue Jul 22 04:57:53 2008 Return-Path: X-Original-To: netconf-archive@lists.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 291D73A695F; Tue, 22 Jul 2008 04:57:53 -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 2350C3A6950 for ; Tue, 22 Jul 2008 04:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 R-PIyuHnbEU4 for ; Tue, 22 Jul 2008 04:57:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7D5933A6915 for ; Tue, 22 Jul 2008 04:57:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EA3C2098D; Tue, 22 Jul 2008 13:58:30 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-bf-4885cb6502cf Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DF23F20986; Tue, 22 Jul 2008 13:58:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:58:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:58:09 +0200 Message-ID: <4885CB51.1000703@ericsson.com> Date: Tue, 22 Jul 2008 13:58:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mark Scott , Sharon Chisholm , Martin Bjorklund X-OriginalArrivalTime: 22 Jul 2008 11:58:09.0387 (UTC) FILETIME=[3598ABB0:01C8EBF2] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0948871154==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0948871154== Content-Type: multipart/alternative; boundary="------------010906060907030609080102" This is a multi-part message in MIME format. --------------010906060907030609080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Marc, Sharon, Martin, I reviewed the draft NETCONF Monitoring Schema. Please find my comments below. General comments) - The comments/descriptions in the YANG and the XSD should be the same. Abstract) Remove the word dynamically, IMHO it does not mean anything Definition of terms) Remove Element, not used Operation refers to the notifications, change it! Mention YANG I was wondering if schema or model or model fragment is the correct term ? 2.1.1. capabilities From RFC4741: "The device uses capabilities to announce the set From netconf-bounces@ietf.org Tue Jul 22 04:57:53 2008 Return-Path: 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 291D73A695F; Tue, 22 Jul 2008 04:57:53 -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 2350C3A6950 for ; Tue, 22 Jul 2008 04:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 R-PIyuHnbEU4 for ; Tue, 22 Jul 2008 04:57:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7D5933A6915 for ; Tue, 22 Jul 2008 04:57:50 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2EA3C2098D; Tue, 22 Jul 2008 13:58:30 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-bf-4885cb6502cf Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DF23F20986; Tue, 22 Jul 2008 13:58:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:58:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 13:58:09 +0200 Message-ID: <4885CB51.1000703@ericsson.com> Date: Tue, 22 Jul 2008 13:58:09 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Mark Scott , Sharon Chisholm , Martin Bjorklund X-OriginalArrivalTime: 22 Jul 2008 11:58:09.0387 (UTC) FILETIME=[3598ABB0:01C8EBF2] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0948871154==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0948871154== Content-Type: multipart/alternative; boundary="------------010906060907030609080102" This is a multi-part message in MIME format. --------------010906060907030609080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Marc, Sharon, Martin, I reviewed the draft NETCONF Monitoring Schema. Please find my comments below. General comments) - The comments/descriptions in the YANG and the XSD should be the same. Abstract) Remove the word dynamically, IMHO it does not mean anything Definition of terms) Remove Element, not used Operation refers to the notifications, change it! Mention YANG I was wondering if schema or model or model fragment is the correct term ? 2.1.1. capabilities From RFC4741: "The device uses capabilities to announce the set of datof data models that the device implements." This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this. Remove minimally. I think all capabilities MUST be advertised already in the HELLO message; or are you thinking of new capabilities/models that appear during a session? 2.1.2. configurations The list of nodes is the authoritative information on a partial lock. Please place it before the select leaf. The select is only provided for completeness, to show the original intent of the locking entity and is only informational. 2.1.6 Statistics - Maybe clarify that we only provide Netconf statistics. - On page 38 for inSessions you have a short expression identifying how the different counters relate to each other. More such expressions would be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors - inBadRpcs - inNotSupportedRpcs - Add something like: a Netconf message can be either Hello messages or Rpcs. Would it be interesting to count whether sessions end with close, kill, or loss of transport? The last could indicate problems, while too many kills could indicate hacking or locking problems 5.1 Netconf Monitoring Schema I only briefly checked this part. - Page 18) It is strange that we have separately ConfigurationDatastore and ConfigurationDatastoreType and both are TYPEs. A different name should be chosen for one of them. - I think ncEvent should also be imported - a few things don't have a type e.g. lockedNodes, select - Page 24) Why is ConfigurationDatastoreType not reused from RFC4741? - Will it be possible to add new values to SchemaFormat, TransportType and ProtocolType? It is sure that we will have new things here. (We (Ericsson) already have e.g. LDAP) 5.2 int:host schema This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft! - I think there are some differences between how YANG and this draft defines domainName. They should be aligned! Appendix A YANG - ConfigurationDatastoreType should be defined in a separate netconfRFC4741 module. - SchemaFormat, TransportType and ProtocolType must be choice, as enumerations are not extensible and it is definite that we will have new values for these. - Is the corect name RNG or DSDL - The Netconf container shall be config true. Only containers below it should be config false. It is quite possible that we will later (possibly in another draft/rfc) add stuff under netconf that is configurable or that someone wants to extend it with configurable settings e.g. access control, max-number of paralel sessions. - /netconf/configurations/configuration/locks/lockedBySession should be a keyref - lockedNodes should come before select as lockedNodes is the authoritative information - do we need top level containers like schemas? We could have the list schema directly under /netconf - /netconf/subscriptions/subscription/sessionId should be a keyref X. IANA Considerations Do we register any XML namespaces? I guess so. Shall we also start the YANG registry? regards Balazs --------------010906060907030609080102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Review of draft-ietf-netconf-monitoring-02.txt Hi Marc, Sharon, Martin,

I reviewed the draft NETCONF Monitoring Schema.
Please fa models that the device implements." This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this. Remove minimally. I think all capabilities MUST be advertised already in the HELLO message; or are you thinking of new capabilities/models that appear during a session? 2.1.2. configurations The list of nodes is the authoritative information on a partial lock. Please place it before the select leaf. The select is only provided for completeness, to show the original intent of the locking entity and is only informational. 2.1.6 Statistics - Maybe clarify that we only provide Netconf statistics. - On page 38 for inSessions you have a short expression identifying how the different counters relate to each other. More such expressions would be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors - inBadRpcs - inNotSupportedRpcs - Add something like: a Netconf message can be either Hello messages or Rpcs. Would it be interesting to count whether sessions end with close, kill, or loss of transport? The last could indicate problems, while too many kills could indicate hacking or locking problems 5.1 Netconf Monitoring Schema I only briefly checked this part. - Page 18) It is strange that we have separately ConfigurationDatastore and ConfigurationDatastoreType and both are TYPEs. A different name should be chosen for one of them. - I think ncEvent should also be imported - a few things don't have a type e.g. lockedNodes, select - Page 24) Why is ConfigurationDatastoreType not reused from RFC4741? - Will it be possible to add new values to SchemaFormat, TransportType and ProtocolType? It is sure that we will have new things here. (We (Ericsson) already have e.g. LDAP) 5.2 int:host schema This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft! - I think there are some differences between how YANG and this draft defines domainName. They should be aligned! Appendix A YANG - ConfigurationDatastoreType should be defined in a separate netconfRFC4741 module. - SchemaFormat, TransportType and ProtocolType must be choice, as enumerations are not extensible and it is definite that we will have new values for these. - Is the corect name RNG or DSDL - The Netconf container shall be config true. Only containers below it should be config false. It is quite possible that we will later (possibly in another draft/rfc) add stuff under netconf that is configurable or that someone wants to extend it with configurable settings e.g. access control, max-number of paralel sessions. - /netconf/configurations/configuration/locks/lockedBySession should be a keyref - lockedNodes should come before select as lockedNodes is the authoritative information - do we need top level containers like schemas? We could have the list schema directly under /netconf - /netconf/subscriptions/subscription/sessionId should be a keyref X. IANA Considerations Do we register any XML namespaces? I guess so. Shall we also start the YANG registry? regards Balazs --------------010906060907030609080102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Review of draft-ietf-netconf-monitoring-02.txt Hi Marc, Sharon, Martin,

I reviewed the draft NETCONF Monitoring Schema.
Please find myind my comments below.

General comments)

- The comments/descriptions in the YANG and the XSD should be the same.

Abstract)
Remove the word dynamically, IMHO it does not mean anything

Definition of terms)
Remove Element, not used
Operation refers to the notifications, change it!
Mention YANG

I was wondering if schema or model or model fragment is the correct term ?


2.1.1. capabilities
>From RFC4741: "The device uses capabilities to announce the set of data models that the device implements."
This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this.

Remove minimally. I think all capabilities MUST be advertised already in the HELLO message; or are you thinking of new capabilities/models that appear during a session?

2.1.2. configurations
The list of nodes is the authoritative information on a partial lock. Please place it before the select leaf. The select is only provided for completeness, to show the original intent of the locking entity and is only informational.

2.1.6 Statistics
- Maybe clarify that we only provide Netconf statistics.
- On page 38 for inSessions you have a short expression identifying how the different counters relate to each other. More such expressions would be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors - inBadRpcs - inNotSupportedRpcs
- Add something like: a Netconf message can be either Hello messages or Rpcs.

Would it be interesting to count whether sessions end with close, kill, or loss of transport? The last could indicate problems, while too many kills could indicate hacking or locking problems

5.1 Netconf Monitoring Schema
I only briefly checked this part.
- Page 18) It is strange that we have separately ConfigurationDatastore and ConfigurationDatastoreType and both are TYPEs. A different name should be chosen for one of them.
- I think ncEvent should also be imported
- a few things don't have a type e.g. lockedNodes, select
- Page 24) Why is ConfigurationDatastoreType not reused from RFC4741?

- Will it be possible to add new values to SchemaFormat, TransportType and ProtocolType? It is sure that we will have new things here. (We (Ericsson) already have e.g. LDAP)

5.2 int:host schema
This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft!
- I think there are some differences between how YANG and this draft defines domainName. They should be aligned!


Appendix A YANG

- ConfigurationDatastoreType should be defined in a separate netconfRFC4741 module.
- SchemaFormat, TransportType and ProtocolType must be choice, as enumerations are not extensible and it is definite that we will have new values for these.
- Is the corect name RNG or DSDL
- The Netconf container shall be config true. Only containers below it should be config false. It is quite possible that we will later (possibly in another draft/rfc) add stuff under netconf that is configurable or that someone wants to extend it with configurable settings e.g. access control, max-number of paralel sessions.
- /netconf/configurations/configuration/locks/lockedBySession should be a keyref
- lockedNodes should come before select as lockedNodes is the authoritative information
- do we need top level containers like schemas? We could have the list schema directly under /netconf
- /netconf/subscriptions/subscription/sessionId should be a keyref


X.  IANA Considerations
Do we register any XML namespaces? I guess so.
Shall we also start the YANG registry?



regards Balazs


--------------010906060907030609080102-- --===============0948871154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0948871154==-- comments below.

General comments)

- The comments/descriptions in the YANG and the XSD should be the same.

Abstract)
Remove the word dynamically, IMHO it does not mean anything

Definition of terms)
Remove Element, not used
Operation refers to the notifications, change it!
Mention YANG

I was wondering if schema or model or model fragment is the correct term ?


2.1.1. capabilities
>From RFC4741: "The device uses capabilities to announce the set of data models that the device implements."
This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this.

Remove minimally. I think all capabilities MUST be advertised already in the HELLO message; or are you thinking of new capabilities/models that appear during a session?

2.1.2. configurations
The list of nodes is the authoritative information on a partial lock. Please place it before the select leaf. The select is only provided for completeness, to show the original intent of the locking entity and is only informational.

2.1.6 Statistics
- Maybe clarify that we only provide Netconf statistics.
- On page 38 for inSessions you have a short expression identifying how the different counters relate to each other. More such expressions would be VERY good. E.g. good RPCs = inRPCs - inXMLParseErrors - inBadRpcs - inNotSupportedRpcs
- Add something like: a Netconf message can be either Hello messages or Rpcs.

Would it be interesting to count whether sessions end with close, kill, or loss of transport? The last could indicate problems, while too many kills could indicate hacking or locking problems

5.1 Netconf Monitoring Schema
I only briefly checked this part.
- Page 18) It is strange that we have separately ConfigurationDatastore and ConfigurationDatastoreType and both are TYPEs. A different name should be chosen for one of them.
- I think ncEvent should also be imported
- a few things don't have a type e.g. lockedNodes, select
- Page 24) Why is ConfigurationDatastoreType not reused from RFC4741?

- Will it be possible to add new values to SchemaFormat, TransportType and ProtocolType? It is sure that we will have new things here. (We (Ericsson) already have e.g. LDAP)

5.2 int:host schema
This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft!
- I think there are some differences between how YANG and this draft defines domainName. They should be aligned!


Appendix A YANG

- ConfigurationDatastoreType should be defined in a separate netconfRFC4741 module.
- SchemaFormat, TransportType and ProtocolType must be choice, as enumerations are not extensible and it is definite that we will have new values for these.
- Is the corect name RNG or DSDL
- The Netconf container shall be config true. Only containers below it should be config false. It is quite possible that we will later (possibly in another draft/rfc) add stuff under netconf that is configurable or that someone wants to extend it with configurable settings e.g. access control, max-number of paralel sessions.
- /netconf/configurations/configuration/locks/lockedBySession should be a keyref
- lockedNodes should come before select as lockedNodes is the authoritative information
- do we need top level containers like schemas? We could have the list schema directly under /netconf
- /netconf/subscriptions/subscription/sessionId should be a keyref


X.  IANA Considerations
Do we register any XML namespaces? I guess so.
Shall we also start the YANG registry?



regards Balazs


--------------010906060907030609080102-- --===============0948871154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0948871154==-- From netconf-bounces@ietf.org Tue Jul 22 09:21:18 2008 Return-Path: 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 13D5028B56A; Tue, 22 Jul 2008 09:21:18 -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 D7FBE3A6881 for ; Tue, 22 Jul 2008 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 BxJwoEV0M1Y7 for ; Tue, 22 Jul 2008 09:21:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A3EF23A6965 for ; Tue, 22 Jul 2008 09:21:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGLqc26366; Tue, 22 Jul 2008 16:21:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:21:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <4885CB51.1000703@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjr8kT6TY/nOyDjRc+2Z7NBoJnOgAAIpzVw References: <4885CB51.1000703@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" , "Mark Scott" , "Martin Bjorklund" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279948958==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0279948958== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC17.009CDAF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EC17.009CDAF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Thanks for your comments. Replies inline. =20 Sharon ________________________________ From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 Sent: Tuesday, July 22, 2008 7:58 AM To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Hi Marc, Sharon, Martin,=20 I reviewed the draft NETCONF Monitoring Schema.=20 Please find my comments below.=20 =20 2.1.1. capabilities >From RFC4741: "The device uses capabilities to announce the set of data models that the device implements." This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this.=20 =20 Experience hFrom netconf-bounces@ietf.org Tue Jul 22 09:21:18 2008 Return-Path: X-Original-To: netconf-archive@lists.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 13D5028B56A; Tue, 22 Jul 2008 09:21:18 -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 D7FBE3A6881 for ; Tue, 22 Jul 2008 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 BxJwoEV0M1Y7 for ; Tue, 22 Jul 2008 09:21:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A3EF23A6965 for ; Tue, 22 Jul 2008 09:21:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGLqc26366; Tue, 22 Jul 2008 16:21:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:21:31 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <4885CB51.1000703@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjr8kT6TY/nOyDjRc+2Z7NBoJnOgAAIpzVw References: <4885CB51.1000703@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" , "Mark Scott" , "Martin Bjorklund" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279948958==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0279948958== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC17.009CDAF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EC17.009CDAF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Thanks for your comments. Replies inline. =20 Sharon ________________________________ From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com]=20 Sent: Tuesday, July 22, 2008 7:58 AM To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund Cc: netconf mailing list Subject: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Hi Marc, Sharon, Martin,=20 I reviewed the draft NETCONF Monitoring Schema.=20 Please find my comments below.=20 =20 2.1.1. capabilities >From RFC4741: "The device uses capabilities to announce the set of data models that the device implements." This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this.=20 =20 Experias shown that was a not the best way to get data model definitions. I don't think we need to repeat that advise here. We may want to remove it in an update to RFC4741. =20 5.2 int:host schema This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft!=20 We looked at that and either it didn't meet our needs or there was a namespace issue, either way, we couldn't use it. In general, if we can get better data types by not deriving them from legacy definitions then we should not be afraid to do that. I agree though that this should be a separate document.. =20 Appendix A YANG =20 We probably should only have a pointer to the yang definition stored elsewhere. We can't have any dependencies on the netmod work if we plan on completing on schedule. Anything we include in this ID, even in non-normative form, can't help but be out of date since netmod won't be done when we publish. =20 regards Balazs ------_=_NextPart_001_01C8EC17.009CDAF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of = draft-ietf-netconf-monitoring-02.txt
hi
 
Thanks for your comments.  Replies=20 inline.
 
Sharon

From: Balazs Lengyel=20 [mailto:balazs.lengyel@ericsson.com]
Sent: Tuesday, July 22, = 2008=20 7:58 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon = (CAR:ZZ00);=20 Martin Bjorklund
Cc: netconf mailing list
Subject: = [Netconf]=20 Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, Martin,=20

I reviewed the draft = NETCONF=20 Monitoring Schema.
Please find my comments below.

 <clip> <= FONT=20 face=3DVerdana>


2.1.1. capabilities
From RFC4741: "The device uses = capabilities to=20 announce the set of data models that the device implements."
This to = me means=20 that the device MUST advertise all it's models as capabilities as well. = So the=20 models will be included both in the capabilities and the schemas branch. = Please=20 indicate this. 

 <sharon> =20 5.2 int:host schema This should be a separate draft as many other will need it. Is there today no XML schema for such basic stuff? Can we refer to draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? Anyone who cares about XSD should start pushing that draft!=20 We looked at that and either it didn't meet our needs or there was a namespace issue, either way, we couldn't use it. In general, if we can get better data types by not deriving them from legacy definitions then we should not be afraid to do that. I agree though that this should be a separate document.. =20 Appendix A YANG =20 We probably should only have a pointer to the yang definition stored elsewhere. We can't have any dependencies on the netmod work if we plan on completing on schedule. Anything we include in this ID, even in non-normative form, can't help but be out of date since netmod won't be done when we publish. =20 regards Balazs ------_=_NextPart_001_01C8EC17.009CDAF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of = draft-ietf-netconf-monitoring-02.txt
hi
 
Thanks for your comments.  Replies=20 inline.
 
Sharon

From: Balazs Lengyel=20 [mailto:balazs.lengyel@ericsson.com]
Sent: Tuesday, July 22, = 2008=20 7:58 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon = (CAR:ZZ00);=20 Martin Bjorklund
Cc: netconf mailing list
Subject: = [Netconf]=20 Review of draft-ietf-netconf-monitoring-02.txt

Hi Marc, Sharon, Martin,=20

I reviewed the draft = NETCONF=20 Monitoring Schema.
Please find my comments below.

 <clip> <= FONT=20 face=3DVerdana>


2.1.1. capabilities
From RFC4741: "The device uses = capabilities to=20 announce the set of data models that the device implements."
This to = me means=20 that the device MUST advertise all it's models as capabilities as well. = So the=20 models will be included both in the capabilities and the schemas branch. = Please=20 indicate this. 

 <sharon&gNT>
Experience has shown that was a not the best = way to get=20 data model definitions.  I don't think we need to repeat that = advise here.=20 We may want to remove it in an update to=20 RFC4741.
</sharon>  

5.2 int:host = schema
This should be=20 a separate draft as many other will need it. Is there today no XML = schema for=20 such basic stuff? Can we refer to=20 draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state = of that?=20 Anyone who cares about XSD should start pushing that draft! 

<sharon>

We=20 looked at that and either it didn't meet our needs or there was a = namespace=20 issue, either way, we couldn't use it. In general, if we can get better = data=20 types by not deriving them from legacy definitions then we should not be = afraid=20 to do that. I agree though that this should be a separate=20 document..

</sharon>

 
Appendix A = YANG

 <clip a long list of issues>

<sharon>  
 We probably should only have a  pointer to the = yang=20 definition stored elsewhere. We can't have any dependencies on  the = netmod=20 work if we plan on completing on schedule. Anything we include in this = ID, even=20 in non-normative form, can't help but be out of date since netmod  = won't be=20 done when we publish.

</sharon> 



regards Balazs


------_=_NextPart_001_01C8EC17.009CDAF3-- --===============0279948958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0279948958==-- t;
Experience has shown that was a not the best = way to get=20 data model definitions.  I don't think we need to repeat that = advise here.=20 We may want to remove it in an update to=20 RFC4741.
</sharon>  

5.2 int:host = schema
This should be=20 a separate draft as many other will need it. Is there today no XML = schema for=20 such basic stuff? Can we refer to=20 draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state = of that?=20 Anyone who cares about XSD should start pushing that draft! 

<sharon>

We=20 looked at that and either it didn't meet our needs or there was a = namespace=20 issue, either way, we couldn't use it. In general, if we can get better = data=20 types by not deriving them from legacy definitions then we should not be = afraid=20 to do that. I agree though that this should be a separate=20 document..

</sharon>

 
Appendix A = YANG

 <clip a long list of issues>

<sharon>  
 We probably should only have a  pointer to the = yang=20 definition stored elsewhere. We can't have any dependencies on  the = netmod=20 work if we plan on completing on schedule. Anything we include in this = ID, even=20 in non-normative form, can't help but be out of date since netmod  = won't be=20 done when we publish.

</sharon> 



regards Balazs


------_=_NextPart_001_01C8EC17.009CDAF3-- --===============0279948958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0279948958==-- From netconf-bounces@ietf.org Tue Jul 22 09:26:36 2008 Return-Path: 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 4E43B3A6881; Tue, 22 Jul 2008 09:26:36 -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 B52D53A6881 for ; Tue, 22 Jul 2008 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IH4eG5EABHeM for ; Tue, 22 Jul 2008 09:26:34 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A3AF13A683F for ; Tue, 22 Jul 2008 09:26:34 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGRC814353; Tue, 22 Jul 2008 16:27:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:27:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945050@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjrCWrf22XotsfZTqeCi4yQt6ScVgBDc/gQ References: From: "Sharon Chisholm" To: "Ersue, Mehmet (NSN - DE/Muenich)" , "Mark Scott" , "Martin Bjorklund" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1295320985==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1295320985== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC17.CB1BB465" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EC17.CB1BB465 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Thanks for your comments. Reply inline. ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Monday, July 21, 2008 4:12 AM To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund Cc: netconf mailing list; ext Bert Wijnen (IETF) Subject: Review of draft-ietf-netconf-monitoring-02.txt 2.1.3. schemas=20 - I would delete the statement on RPC in 2.1.3. and add=20 in chapter "3.1 New NETCONF RPC, " that get-schema is=20 using the same elements as defined in chapter 2.1.3. The chapter 3.1.=20 should be self-explaining and include all necessary information. =20 Technically, I think the term should be 'operation' not 'RPC'. We should make this correction throughout the ID. =20 Cheers,=20 Mehmet=20 ------_=_NextPart_001_01C8EC17.CB1BB465 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of = draft-ietf-netconf-monitoring-02.txt
hi
 
Thanks for your comments. Reply=20 inline.

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Monday, July 21, 2008 = 4:12=20 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); = Martin=20 Bjorklund
Cc: netconf mailing list; ext Bert Wijnen=20 (IETF)
Subject: Review of=20 draft-ietf-netconf-monitoring-02.txt


 <clip>=

 2.1.3. schemas

- I would delete the = statement on=20 <get-schema> RPC in 2.1.3. and add
in chapter "3.1 New NETCONF RPC, = <get-schema>" that=20 get-schema is
using=20 the same elements as defined in chapter 2.1.3. The chapter 3.1.=20
should = be=20 self-explaining and include all necessary = information.  

<sharon>

Technically,  I think the term should be 'operation' not = 'RPC'. We=20 should make this correction throughout the ID.

</sharon> 

<clip>

Cheers, =
Mehmet =

------_=_NextPart_001_01C8EC17.CB1BB465-- --===============1295320985== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1295320985==-- From netconf-bounces@ietf.org Tue Jul 22 09:26:36 2008 Return-Path: X-Original-To: netconf-archive@lists.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 4E43B3A6881; Tue, 22 Jul 2008 09:26:36 -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 B52D53A6881 for ; Tue, 22 Jul 2008 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IH4eG5EABHeM for ; Tue, 22 Jul 2008 09:26:34 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A3AF13A683F for ; Tue, 22 Jul 2008 09:26:34 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGRC814353; Tue, 22 Jul 2008 16:27:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:27:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945050@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjrCWrf22XotsfZTqeCi4yQt6ScVgBDc/gQ References: From: "Sharon Chisholm" To: "Ersue, Mehmet (NSN - DE/Muenich)" , "Mark Scott" , "Martin Bjorklund" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1295320985==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1295320985== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC17.CB1BB465" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EC17.CB1BB465 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Thanks for your comments. Reply inline. ________________________________ From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com]=20 Sent: Monday, July 21, 2008 4:12 AM To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund Cc: netconf mailing list; ext Bert Wijnen (IETF) Subject: Review of draft-ietf-netconf-monitoring-02.txt 2.1.3. schemas=20 - I would delete the statement on RPC in 2.1.3. and add=20 in chapter "3.1 New NETCONF RPC, " that get-schema is=20 using the same elements as defined in chapter 2.1.3. The chapter 3.1.=20 should be self-explaining and include all necessary information. =20 Technically, I think the term should be 'operation' not 'RPC'. We should make this correction throughout the ID. =20 Cheers,=20 Mehmet=20 ------_=_NextPart_001_01C8EC17.CB1BB465 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of = draft-ietf-netconf-monitoring-02.txt
hi
 
Thanks for your comments. Reply=20 inline.

From: Ersue, Mehmet (NSN - = DE/Muenich)=20 [mailto:mehmet.ersue@nsn.com]
Sent: Monday, July 21, 2008 = 4:12=20 AM
To: Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); = Martin=20 Bjorklund
Cc: netconf mailing list; ext Bert Wijnen=20 (IETF)
Subject: Review of=20 draft-ietf-netconf-monitoring-02.txt


 <clip>=

 2.1.3. schemas

- I would delete the = statement on=20 <get-schema> RPC in 2.1.3. and add
in chapter "3.1 New NETCONF RPC, = <get-schema>" that=20 get-schema is
using=20 the same elements as defined in chapter 2.1.3. The chapter 3.1.=20
should = be=20 self-explaining and include all necessary = information.  

<sharon>

Technically,  I think the term should be 'operation' not = 'RPC'. We=20 should make this correction throughout the ID.

</sharon> 

<clip>

Cheers, =
Mehmet =

------_=_NextPart_001_01C8EC17.CB1BB465-- --===============1295320985== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1295320985==-- From netconf-bounces@ietf.org Tue Jul 22 09:29:14 2008 Return-Path: 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 4D6543A6881; Tue, 22 Jul 2008 09:29:14 -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 4374F3A6881 for ; Tue, 22 Jul 2008 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 OeDrgAFmSaDG for ; Tue, 22 Jul 2008 09:29:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D4ED23A683F for ; Tue, 22 Jul 2008 09:29:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 12F6D2076B; Tue, 22 Jul 2008 18:29:52 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-0a-48860aff7107 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBDCC203ED; Tue, 22 Jul 2008 18:29:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:29:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:29:51 +0200 Message-ID: <48860FAF.2060300@ericsson.com> Date: Tue, 22 Jul 2008 18:49:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: X-OriginalArrivalTime: 22 Jul 2008 16:29:51.0721 (UTC) FILETIME=[2A8B6D90:01C8EC18] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Mehmet, Thanks for the comments. See also below. Balazs Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Hi Balazs, > > I reviewed the draft "Partial Lock RPC for NETCONF". > Please find my comments below. > > General comments: > > - The document looks good. Do you think we should bring it with > an updated version to WGLC after the IETF meeting? {BALAZS}: Yes, I believe it should go to WGLC. > > - Are we going to register the XML Schema at IANA as we did for > RFC 5277? In any case I would suggest to have the Schema as > self-explaining. {BALAZS}: I will add comments, annotations > > > Comments per chapter: > > 2.1. Overview > > - "The system MUST ensure . . ." > > I don't know how to ensure this if it is a non-NETCONF management system. > The statement sounds like a normative statement but it does not cover > any standard-relevant definition. It is actually a generic statement and > I would suggest to find another formulation than "MUST". {BALAZS}: I am not sure I understand your comment. The system (the netconf server) IS a NETCONF system, otherwise it would not implement Netconf partial locking. I see this as a requirement on the Netconf server, not just a generic statement so I think MUST is appropriate. RFC4741 uses MUST when describing global lock "the server MUST prevent any changes to the locked resource". Earlier I had "The system ensures" but someone had a comment to use MUST. > > - I would split the 3rd paragraph into two sentences for more clarity: > "The duration of the partial lock is defined as beginning when the > partial lock is granted. The partial lock lasts until either the > corresponding > operation succeeds or the NETCONF session terminates." {BALAZS}: OK > > 2.2. Dependencies > > s/in _Section 2.4.1_ > /in > _Section 2.4.1_ > ./ {BALAZS}: OK > > > 2.4.1. > > - I would indicate the beginning of the description part of the > > operation with: > > - I would suggest to indicate that the the "portion of the data store" is a > "coherent set of nodes". {BALAZS}: Sorry what do you mean by COHERENT set of nodes? Could you explain it please. The set of nodes can consist of 10 disconnected individual nodes/subtrees if the XPATH expressions are specified that way. > > - 6th paragraph: "If a top level node of a locked subtree is deleted, . > . ." > > Why is it necessary to keep the lock with a "nil scope" present? > I would expect that a lock with a nil scope is not needed and should not > be kept. {BALAZS}: It is not nice if a lock just disappears. If the manager SW later comes and tries to unlock it and gets back an error he might be surprised. At this point the manager will need extra checks to see, whether the error was caused by a removed empty lock or other error. But if the workgroup insists this could be changed. > > - s/A partial lock MUST fail/A partial lock operation MUST fail/ {BALAZS}: OK > > - 2nd bullet: " o Any part of the scope to be locked is already locked > . . ." > > I think we should have a note here to explain why we think that a partial > lock can be also introduced by a non-NETCONF management system and > how this could be realized. > I agree with an earlier comment that Netconf locking (both global and > partial) > is creating new requirements for SNMP and other protocols. I would propose > to explain the impact on other management protocols in this note. {BALAZS}: I need to think about this comment a bit. The new requirement is not really on the other protocol handlers, but the instrumentation behind the protocols. It needs to respect the Netconf partial-lock which is stated in 2.1 paragraph 2. If the other protocols also want to use their own partial-locking, that is their own decision but that is not a _requirement_ for implementors of this draft. The other protocols can still use a global lock. > > - s/If the select expressions return/If the select expression returns/ {BALAZS}: OK > > > 2.5. Modifications to Existing Operations > > I would reorganize the first sentence for more clarity, e.g.: > "A granted partial-lock will cause operations to fail, if it wants to > modify > the already locked area and is executed in a NETCONF session other > than the one that owns the lock." {BALAZS}: OK > > 3. Security Considerations > > Do the two sub-paragraphs below belong into the security considerations > or should they be put to the end of the paragraph 2.4.2. ? > They have at least to do with releasing of locks. > > "The partial-lock is automatically released when . . . > The operation allows terminating other users . . ." {BALAZS}: Earlier in 2.1 para 3. we already stated that terminating the session releases the lock. These paragraphs are placed here to emphasize, how we can avoid a DOS attack based on partial-locking. > > 5. Appendix A - XML Schema for Partial Locking (normative) > > Please add the element descriptions in the YANG module also into the XML > Schema as documentation to get it self-explaining. {BALAZS}: OK > > Cheers, > Mehmet > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:29:14 2008 Return-Path: X-Original-To: netconf-archive@lists.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 4D6543A6881; Tue, 22 Jul 2008 09:29:14 -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 4374F3A6881 for ; Tue, 22 Jul 2008 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 OeDrgAFmSaDG for ; Tue, 22 Jul 2008 09:29:12 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D4ED23A683F for ; Tue, 22 Jul 2008 09:29:11 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 12F6D2076B; Tue, 22 Jul 2008 18:29:52 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-0a-48860aff7107 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DBDCC203ED; Tue, 22 Jul 2008 18:29:51 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:29:51 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:29:51 +0200 Message-ID: <48860FAF.2060300@ericsson.com> Date: Tue, 22 Jul 2008 18:49:51 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: X-OriginalArrivalTime: 22 Jul 2008 16:29:51.0721 (UTC) FILETIME=[2A8B6D90:01C8EC18] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Mehmet, Thanks for the comments. See also below. Balazs Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Hi Balazs, > > I reviewed the draft "Partial Lock RPC for NETCONF". > Please find my comments below. > > General comments: > > - The document looks good. Do you think we should bring it with > an updated version to WGLC after the IETF meeting? {BALAZS}: Yes, I believe it should go to WGLC. > > - Are we going to register the XML Schema at IANA as we did for > RFC 5277? In any case I would suggest to have the Schema as > self-explaining. {BALAZS}: I will add comments, annotations > > > Comments per chapter: > > 2.1. Overview > > - "The system MUST ensure . . ." > > I don't know how to ensure this if it is a non-NETCONF management system. > The statement sounds like a normative statement but it does not cover > any standard-relevant definition. It is actually a generic statement and > I would suggest to find another formulation than "MUST". {BALAZS}: I am not sure I understand your comment. The system (the netconf server) IS a NETCONF system, otherwise it would not implement Netconf partial locking. I see this as a requirement on the Netconf server, not just a generic statement so I think MUST is appropriate. RFC4741 uses MUST when describing global lock "the server MUST prevent any changes to the locked resource". Earlier I had "The system ensures" but someone had a comment to use MUST. > > - I would split the 3rd paragraph into two sentences for more clarity: > "The duration of the partial lock is defined as beginning when the > partial lock is granted. The partial lock lasts until either the > corresponding > operation succeeds or the NETCONF session terminates." {BALAZS}: OK > > 2.2. Dependencies > > s/in _Section 2.4.1_ > /in > _Section 2.4.1_ > ./ {BALAZS}: OK > > > 2.4.1. > > - I would indicate the beginning of the description part of the > > operation with: > > - I would suggest to indicate that the the "portion of the data store" is a > "coherent set of nodes". {BALAZS}: Sorry what do you mean by COHERENT set of nodes? Could you explain it please. The set of nodes can consist of 10 disconnected individual nodes/subtrees if the XPATH expressions are specified that way. > > - 6th paragraph: "If a top level node of a locked subtree is deleted, . > . ." > > Why is it necessary to keep the lock with a "nil scope" present? > I would expect that a lock with a nil scope is not needed and should not > be kept. {BALAZS}: It is not nice if a lock just disappears. If the manager SW later comes and tries to unlock it and gets back an error he might be surprised. At this point the manager will need extra checks to see, whether the error was caused by a removed empty lock or other error. But if the workgroup insists this could be changed. > > - s/A partial lock MUST fail/A partial lock operation MUST fail/ {BALAZS}: OK > > - 2nd bullet: " o Any part of the scope to be locked is already locked > . . ." > > I think we should have a note here to explain why we think that a partial > lock can be also introduced by a non-NETCONF management system and > how this could be realized. > I agree with an earlier comment that Netconf locking (both global and > partial) > is creating new requirements for SNMP and other protocols. I would propose > to explain the impact on other management protocols in this note. {BALAZS}: I need to think about this comment a bit. The new requirement is not really on the other protocol handlers, but the instrumentation behind the protocols. It needs to respect the Netconf partial-lock which is stated in 2.1 paragraph 2. If the other protocols also want to use their own partial-locking, that is their own decision but that is not a _requirement_ for implementors of this draft. The other protocols can still use a global lock. > > - s/If the select expressions return/If the select expression returns/ {BALAZS}: OK > > > 2.5. Modifications to Existing Operations > > I would reorganize the first sentence for more clarity, e.g.: > "A granted partial-lock will cause operations to fail, if it wants to > modify > the already locked area and is executed in a NETCONF session other > than the one that owns the lock." {BALAZS}: OK > > 3. Security Considerations > > Do the two sub-paragraphs below belong into the security considerations > or should they be put to the end of the paragraph 2.4.2. ? > They have at least to do with releasing of locks. > > "The partial-lock is automatically released when . . . > The operation allows terminating other users . . ." {BALAZS}: Earlier in 2.1 para 3. we already stated that terminating the session releases the lock. These paragraphs are placed here to emphasize, how we can avoid a DOS attack based on partial-locking. > > 5. Appendix A - XML Schema for Partial Locking (normative) > > Please add the element descriptions in the YANG module also into the XML > Schema as documentation to get it self-explaining. {BALAZS}: OK > > Cheers, > Mehmet > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:38:06 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1BAC328C13F; Tue, 22 Jul 2008 09:38:06 -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 35C2428C137 for ; Tue, 22 Jul 2008 09:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 mPgCwqjYz5Co for ; Tue, 22 Jul 2008 09:38:04 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 2C1163A6A5F for ; Tue, 22 Jul 2008 09:38:04 -0700 (PDT) Received: (qmail 44509 invoked from network); 22 Jul 2008 16:38:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 16:38:43 -0000 X-YMail-OSG: RrATmYUVM1kIvKyvwTQYLwU3pMKpwJ8wm3k3NemhpTUaKDE7pDRJJO_.s_pfILAbpxf7Bq_q25HU8BWUGAcQL56qc.EM5wYM9BTLxOzva2S18M0dBV4iP_1PUGOoQGTkKp2xDlwfBP9XqehQOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48860D11.3000203@netconfcentral.com> Date: Tue, 22 Jul 2008 09:38:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > hi > > Thanks for your comments. Replies inline. > > Sharon > > ------------------------------------------------------------------------ > *From:* Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > *Sent:* Tuesday, July 22, 2008 7:58 AM > *To:* Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund > *Cc:* netconf mailing list > *Subject:* [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi Marc, Sharon, Martin, > > I reviewed the draft NETCONF Monitoring Schema. > Please find my comments below. > > > > > 2.1.1. capabilities > From RFC4741: "The device uses capabilities to announce the set of data > models that the device implements." > This to me means that the device MUST advertise all it's models as > capabilities as well. So the models will be included both in the > capabilities and the schemas branch. Please indicate this. > > > Experience has shown that was a not the best way to get data model > definitions. I don't think we need to repeat that advise here. We may > want to remove it in an update to RFC4741. > > I think it is useful to send the module capabilities in the . The very first the manager needs to do is get these module caps, so it can make sure compatible versions of all the relevant modules are loaded. Unless the manager is using a proprietary mechanism (e.g., identifying packages or profiles, not individual modules), then it will take the same amount of bandwidth and memory for the as the . I support an additional for module-caps, because the alternative is to rely on a proprietary API to access the message. Andy > 5.2 int:host schema > This should be a separate draft as many other will need it. Is there > today no XML schema for such basic stuff? Can we refer to > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > Anyone who cares about XSD should start pushing that draft! > > > > We looked at that and either it didn't meet our needs or there was a > namespace issue, either way, we couldn't use it. In general, if we can > get better data types by not deriving them from legacy definitions then > we should not be afraid to do that. I agree though that this should be a > separate document.. > > > > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we plan > on completing on schedule. Anything we include in this ID, even in > non-normative form, can't help but be out of date since netmod won't be > done when we publish. > > > > > > regards Balazs > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From netconf-bounces@ietf.org Tue Jul 22 09:38:06 2008 Return-Path: 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 1BAC328C13F; Tue, 22 Jul 2008 09:38:06 -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 35C2428C137 for ; Tue, 22 Jul 2008 09:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 mPgCwqjYz5Co for ; Tue, 22 Jul 2008 09:38:04 -0700 (PDT) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by core3.amsl.com (Postfix) with SMTP id 2C1163A6A5F for ; Tue, 22 Jul 2008 09:38:04 -0700 (PDT) Received: (qmail 44509 invoked from network); 22 Jul 2008 16:38:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 16:38:43 -0000 X-YMail-OSG: RrATmYUVM1kIvKyvwTQYLwU3pMKpwJ8wm3k3NemhpTUaKDE7pDRJJO_.s_pfILAbpxf7Bq_q25HU8BWUGAcQL56qc.EM5wYM9BTLxOzva2S18M0dBV4iP_1PUGOoQGTkKp2xDlwfBP9XqehQOQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48860D11.3000203@netconfcentral.com> Date: Tue, 22 Jul 2008 09:38:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Sharon Chisholm References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > hi > > Thanks for your comments. Replies inline. > > Sharon > > ------------------------------------------------------------------------ > *From:* Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > *Sent:* Tuesday, July 22, 2008 7:58 AM > *To:* Scott, Mark (CAR:2Y01); Chisholm, Sharon (CAR:ZZ00); Martin Bjorklund > *Cc:* netconf mailing list > *Subject:* [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi Marc, Sharon, Martin, > > I reviewed the draft NETCONF Monitoring Schema. > Please find my comments below. > > > > > 2.1.1. capabilities > From RFC4741: "The device uses capabilities to announce the set of data > models that the device implements." > This to me means that the device MUST advertise all it's models as > capabilities as well. So the models will be included both in the > capabilities and the schemas branch. Please indicate this. > > > Experience has shown that was a not the best way to get data model > definitions. I don't think we need to repeat that advise here. We may > want to remove it in an update to RFC4741. > > I think it is useful to send the module capabilities in the . The very first the manager needs to do is get these module caps, so it can make sure compatible versions of all the relevant modules are loaded. Unless the manager is using a proprietary mechanism (e.g., identifying packages or profiles, not individual modules), then it will take the same amount of bandwidth and memory for the as the . I support an additional for module-caps, because the alternative is to rely on a proprietary API to access the message. Andy > 5.2 int:host schema > This should be a separate draft as many other will need it. Is there > today no XML schema for such basic stuff? Can we refer to > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > Anyone who cares about XSD should start pushing that draft! > > > > We looked at that and either it didn't meet our needs or there was a > namespace issue, either way, we couldn't use it. In general, if we can > get better data types by not deriving them from legacy definitions then > we should not be afraid to do that. I agree though that this should be a > separate document.. > > > > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we plan > on completing on schedule. Anything we include in this ID, even in > non-normative form, can't help but be out of date since netmod won't be > done when we publish. > > > > > > regards Balazs > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 From netconf-bounces@ietf.org Tue Jul 22 09:42:15 2008 Return-Path: X-Original-To: netconf-archive@lists.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 AB31B3A6A47; Tue, 22 Jul 2008 09:42:15 -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 85A3A3A68A5 for ; Tue, 22 Jul 2008 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 h1ehO8oUspt6 for ; Tue, 22 Jul 2008 09:42:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8BC1C28C0FD for ; Tue, 22 Jul 2008 09:42:08 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2807620A87; Tue, 22 Jul 2008 18:42:48 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-7e-48860e066527 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52C5520A72; Tue, 22 Jul 2008 18:42:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:42:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:42:45 +0200 Message-ID: <4886150C.7090104@ericsson.com> Date: Tue, 22 Jul 2008 19:12:44 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48860D11.3000203@netconfcentral.com> In-Reply-To: <48860D11.3000203@netconfcentral.com> X-OriginalArrivalTime: 22 Jul 2008 16:42:45.0631 (UTC) FILETIME=[F7D4B8F0:01C8EC19] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Andy Bierman wrote: >> >> 2.1.1. capabilities >> From RFC4741: "The device uses capabilities to announce the set of >> data models that the device implements." >> This to me means that the device MUST advertise all it's models as >> capabilities as well. So the models will be included both in the >> capabilities and the schemas branch. Please indicate this. >> >> Experience has shown that was a not the best way to get data model >> definitions. I don't think we need to repeat that advise here. We may >> want to remove it in an update to RFC4741. >> > > I think it is useful to send the module capabilities in the . > The very first the manager needs to do is get these module caps, > so it can make sure compatiFrom netconf-bounces@ietf.org Tue Jul 22 09:42:15 2008 Return-Path: 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 AB31B3A6A47; Tue, 22 Jul 2008 09:42:15 -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 85A3A3A68A5 for ; Tue, 22 Jul 2008 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 h1ehO8oUspt6 for ; Tue, 22 Jul 2008 09:42:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8BC1C28C0FD for ; Tue, 22 Jul 2008 09:42:08 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2807620A87; Tue, 22 Jul 2008 18:42:48 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-7e-48860e066527 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 52C5520A72; Tue, 22 Jul 2008 18:42:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:42:45 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:42:45 +0200 Message-ID: <4886150C.7090104@ericsson.com> Date: Tue, 22 Jul 2008 19:12:44 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48860D11.3000203@netconfcentral.com> In-Reply-To: <48860D11.3000203@netconfcentral.com> X-OriginalArrivalTime: 22 Jul 2008 16:42:45.0631 (UTC) FILETIME=[F7D4B8F0:01C8EC19] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Andy Bierman wrote: >> >> 2.1.1. capabilities >> From RFC4741: "The device uses capabilities to announce the set of >> data models that the device implements." >> This to me means that the device MUST advertise all it's models as >> capabilities as well. So the models will be included both in the >> capabilities and the schemas branch. Please indicate this. >> >> Experience has shown that was a not the best way to get data model >> definitions. I don't think we need to repeat that advise here. We may >> want to remove it in an update to RFC4741. >> > > I think it is useful to send the module capabilities in the . > The very first the manager needs to do is get these module caps, > so it can make sure compatible veble versions of all the relevant modules > are loaded. Unless the manager is using a proprietary mechanism > (e.g., identifying packages or profiles, not individual modules), > then it will take the same amount of bandwidth and memory for > the as the . > > > Andy Andy, according to RFC4741 do you consider it mandatory to advertise all data models? - yes - no - yes, but as this is a mistake, we should forget it? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf rsions of all the relevant modules > are loaded. Unless the manager is using a proprietary mechanism > (e.g., identifying packages or profiles, not individual modules), > then it will take the same amount of bandwidth and memory for > the as the . > > > Andy Andy, according to RFC4741 do you consider it mandatory to advertise all data models? - yes - no - yes, but as this is a mistake, we should forget it? Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:49:08 2008 Return-Path: X-Original-To: netconf-archive@lists.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 E160C3A6918; Tue, 22 Jul 2008 09:49:08 -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 DC11D3A6941 for ; Tue, 22 Jul 2008 09:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 HbMgGpK9flKu for ; Tue, 22 Jul 2008 09:49:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8F9033A683F for ; Tue, 22 Jul 2008 09:49:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C34C020261; Tue, 22 Jul 2008 18:49:46 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-78-48860faa6f7d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A139920167; Tue, 22 Jul 2008 18:49:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:49:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:49:46 +0200 Message-ID: <48861909.8030204@ericsson.com> Date: Tue, 22 Jul 2008 19:29:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 22 Jul 2008 16:49:46.0224 (UTC) FILETIME=[F2861F00:01C8EC1A] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > 5.2 int:host schema > This should be a separate draft as many other will need it. Is there > today no XML schema for such basic stuff? Can we refer to > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > Anyone who cares about XSD should start pushing that draft! > > > > We looked at that and either it didn't meet our needs or there was a > namespace issue, either way, we couldn't use it. In general, if we can > get better data types by not deriving them from legacy definitions then > we should not be afraid to do that. I agree though that this should be a > separate document.. > > {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so it can not be legacy. Also Bob Natale indicated to me that he intends to go on working on it, so join forces. > > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we plan > on completing on schedule. Anything we include in this ID, even in > non-normative form, can't help but be out of date since netmod won't be > done when we publish. > > > {BALAZS}: I disagree. I believe making YANG informative deals with the timing. I have already seen the first emails stating that they mostly look at YANG not the XSD. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:49:08 2008 Return-Path: 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 E160C3A6918; Tue, 22 Jul 2008 09:49:08 -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 DC11D3A6941 for ; Tue, 22 Jul 2008 09:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 HbMgGpK9flKu for ; Tue, 22 Jul 2008 09:49:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8F9033A683F for ; Tue, 22 Jul 2008 09:49:06 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C34C020261; Tue, 22 Jul 2008 18:49:46 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-78-48860faa6f7d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A139920167; Tue, 22 Jul 2008 18:49:46 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:49:46 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 18:49:46 +0200 Message-ID: <48861909.8030204@ericsson.com> Date: Tue, 22 Jul 2008 19:29:45 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Sharon Chisholm References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> X-OriginalArrivalTime: 22 Jul 2008 16:49:46.0224 (UTC) FILETIME=[F2861F00:01C8EC1A] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > 5.2 int:host schema > This should be a separate draft as many other will need it. Is there > today no XML schema for such basic stuff? Can we refer to > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > Anyone who cares about XSD should start pushing that draft! > > > > We looked at that and either it didn't meet our needs or there was a > namespace issue, either way, we couldn't use it. In general, if we can > get better data types by not deriving them from legacy definitions then > we should not be afraid to do that. I agree though that this should be a > separate document.. > > {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so it can not be legacy. Also Bob Natale indicated to me that he intends to go on working on it, so join forces. > > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we plan > on completing on schedule. Anything we include in this ID, even in > non-normative form, can't help but be out of date since netmod won't be > done when we publish. > > > {BALAZS}: I disagree. I believe making YANG informative deals with the timing. I have already seen the first emails stating that they mostly look at YANG not the XSD. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:57:41 2008 Return-Path: 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 458963A68D6; Tue, 22 Jul 2008 09:57:41 -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 913313A68D6 for ; Tue, 22 Jul 2008 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 2M1YeSCaWuEr for ; Tue, 22 Jul 2008 09:57:39 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A26E73A68CD for ; Tue, 22 Jul 2008 09:57:39 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGwHh24460; Tue, 22 Jul 2008 16:58:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:58:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945100@zcarhxm2.corp.nortel.com> In-Reply-To: <48861909.8030204@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjsGvUjcjTRtRTBS+OmqrrzOtW0QwAALUFg References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we > plan on completing on schedule. Anything we include in this ID, even > in non-normative form, can't help but be out of date since netmod > won't be done when we publish. > > > {BALAZS}: I disagree. I believe making YANG informative deals with the timing. I have already seen the first emails stating that they mostly look at YANG not the XSD. This isn't a beauty contest question. We have a normative language for defining content at the moment and we have work in progress. As I stated, we need to minimize the dependencies in the draft on work in progress. If some people find it useful to also having netmod stuff available, I think it makes more sense to do it outside the draft, where it will be easier to keep up to date and the standards evolve. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 09:57:41 2008 Return-Path: X-Original-To: netconf-archive@lists.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 458963A68D6; Tue, 22 Jul 2008 09:57:41 -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 913313A68D6 for ; Tue, 22 Jul 2008 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 2M1YeSCaWuEr for ; Tue, 22 Jul 2008 09:57:39 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A26E73A68CD for ; Tue, 22 Jul 2008 09:57:39 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6MGwHh24460; Tue, 22 Jul 2008 16:58:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 12:58:13 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945100@zcarhxm2.corp.nortel.com> In-Reply-To: <48861909.8030204@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjsGvUjcjTRtRTBS+OmqrrzOtW0QwAALUFg References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> From: "Sharon Chisholm" To: "Balazs Lengyel" Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > > Appendix A YANG > > > > > We probably should only have a pointer to the yang definition stored > elsewhere. We can't have any dependencies on the netmod work if we > plan on completing on schedule. Anything we include in this ID, even > in non-normative form, can't help but be out of date since netmod > won't be done when we publish. > > > {BALAZS}: I disagree. I believe making YANG informative deals with the timing. I have already seen the first emails stating that they mostly look at YANG not the XSD. This isn't a beauty contest question. We have a normative language for defining content at the moment and we have work in progress. As I stated, we need to minimize the dependencies in the draft on work in progress. If some people find it useful to also having netmod stuff available, I think it makes more sense to do it outside the draft, where it will be easier to keep up to date and the standards evolve. Sharon _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 10:24:41 2008 Return-Path: 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 5517E3A695D; Tue, 22 Jul 2008 10:24:41 -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 C584F3A69A4 for ; Tue, 22 Jul 2008 10:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] 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 iorUwhGYjQVr for ; Tue, 22 Jul 2008 10:24:38 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id CA5513A695D for ; Tue, 22 Jul 2008 10:24:38 -0700 (PDT) Received: (qmail 39733 invoked from network); 22 Jul 2008 17:25:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 17:25:15 -0000 X-YMail-OSG: 3ZfwJGYVM1lKiRuPtNebDGeAooYsj1qo1oLW.2eapcY6TpUaCQ_W6OLgmW._dAAF_jKS3R11y_g9FBb6i4l7kw8SQMpaeW0GTCGC8ispWriECRKFCKZLxi9Y6k7s X-Yahoo-Newman-Property: ymail-3 Message-ID: <488617F8.1060907@netconfcentral.com> Date: Tue, 22 Jul 2008 10:25:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48860D11.3000203@netconfcentral.com> <4886150C.7090104@ericsson.com> In-Reply-To: <4886150C.7090104@ericsson.com> Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > > Andy Bierman wrote: >>> >>> 2.1.1. capabilities >>> From RFC4741: "The device uses capabilities to announce the set of >>> data models that the device implements." >>> This to me means that the device MUST advertise all it's models as >>> capabilities as well. So the models will be included both in the >>> capabilities and the schemas branch. Please indicate this. >>> >>> Experience has shown that was a not the best way to get data model >>> definitions. I don't think we need to repeat that advise here. We >>> may want to remove it in an update to RFC4741. >>> >> >> I think it is useful to send the module capabilities in the . >> The very first the manager needs to do is get these module caps, >> so it can make sure compatible versions of all the relevant modules >> are loaded. Unless the manager is using a proprietary mechanism >> (e.g., identifying packages or profiles, not individual modules), >> then it will take the same amount of bandwidth and memory for >> the as the . >> > > >> Andy > Andy, according to RFC4741 do you consider it mandatory to advertise all > data models? > - yes > - no > - yes, but as this is a mistake, we should forget it? > No, it is not mandatory. Only the 'base' capability is mandatory, indicating support for the RFC 4741 version of NETCONF. I think it is easier (at many levels) to define a standard data model and standard RPC method, than it is to add additional standard features to the message. (E.g., I don't want to deal with access control for PDUs). I think the NETCONF spec should remain silent on adding proprietary elements, and the schema discovery draft should be the only standard mechanism defined for this purpose. > Balazs Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 10:24:41 2008 Return-Path: X-Original-To: netconf-archive@lists.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 5517E3A695D; Tue, 22 Jul 2008 10:24:41 -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 C584F3A69A4 for ; Tue, 22 Jul 2008 10:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] 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 iorUwhGYjQVr for ; Tue, 22 Jul 2008 10:24:38 -0700 (PDT) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by core3.amsl.com (Postfix) with SMTP id CA5513A695D for ; Tue, 22 Jul 2008 10:24:38 -0700 (PDT) Received: (qmail 39733 invoked from network); 22 Jul 2008 17:25:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2008 17:25:15 -0000 X-YMail-OSG: 3ZfwJGYVM1lKiRuPtNebDGeAooYsj1qo1oLW.2eapcY6TpUaCQ_W6OLgmW._dAAF_jKS3R11y_g9FBb6i4l7kw8SQMpaeW0GTCGC8ispWriECRKFCKZLxi9Y6k7s X-Yahoo-Newman-Property: ymail-3 Message-ID: <488617F8.1060907@netconfcentral.com> Date: Tue, 22 Jul 2008 10:25:12 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Balazs Lengyel References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48860D11.3000203@netconfcentral.com> <4886150C.7090104@ericsson.com> In-Reply-To: <4886150C.7090104@ericsson.com> Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > Hello, > > Andy Bierman wrote: >>> >>> 2.1.1. capabilities >>> From RFC4741: "The device uses capabilities to announce the set of >>> data models that the device implements." >>> This to me means that the device MUST advertise all it's models as >>> capabilities as well. So the models will be included both in the >>> capabilities and the schemas branch. Please indicate this. >>> >>> Experience has shown that was a not the best way to get data model >>> definitions. I don't think we need to repeat that advise here. We >>> may want to remove it in an update to RFC4741. >>> >> >> I think it is useful to send the module capabilities in the . >> The very first the manager needs to do is get these module caps, >> so it can make sure compatible versions of all the relevant modules >> are loaded. Unless the manager is using a proprietary mechanism >> (e.g., identifying packages or profiles, not individual modules), >> then it will take the same amount of bandwidth and memory for >> the as the . >> > > >> Andy > Andy, according to RFC4741 do you consider it mandatory to advertise all > data models? > - yes > - no > - yes, but as this is a mistake, we should forget it? > No, it is not mandatory. Only the 'base' capability is mandatory, indicating support for the RFC 4741 version of NETCONF. I think it is easier (at many levels) to define a standard data model and standard RPC method, than it is to add additional standard features to the message. (E.g., I don't want to deal with access control for PDUs). I think the NETCONF spec should remain silent on adding proprietary elements, and the schema discovery draft should be the only standard mechanism defined for this purpose. > Balazs Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 10:39:59 2008 Return-Path: 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 D287C3A6A24; Tue, 22 Jul 2008 10:39:59 -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 83C873A6991 for ; Tue, 22 Jul 2008 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599] 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 7CaKnW+CF1x0 for ; Tue, 22 Jul 2008 10:39:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1DF943A6A14 for ; Tue, 22 Jul 2008 10:39:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6MHeYB3026055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 19:40:34 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6MHeYWZ023179; Tue, 22 Jul 2008 19:40:34 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 19:40:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 19:40:33 +0200 Message-ID: In-Reply-To: <48860FAF.2060300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-partial-lock-02.txt Thread-Index: AcjsGC1edZVyOxmdQvKZ+YOiNpPUdQAAoV1Q References: <48860FAF.2060300@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 22 Jul 2008 17:40:34.0204 (UTC) FILETIME=[0B42F5C0:01C8EC22] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16048.000 X-TM-AS-Result: No--7.177700-8.000000-31 Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Balazs, we will discuss on WGLC during the NETCONF session. > > - "The system MUST ensure . . ." > > > > I don't know how to ensure this if it is a non-NETCONF management system. > > The statement sounds like a normative statement but it does not cover > > any standard-relevant definition. It is actually a generic statement and > > I would suggest to find another formulation than "MUST". > {BALAZS}: I am not sure I understand your comment. The system > (the netconf server) IS a NETCONF > system, otherwise it would not implement Netconf partial locking. I see this as a requirement > on the Netconf server, not just a generic statement so I tFrom netconf-bounces@ietf.org Tue Jul 22 10:39:59 2008 Return-Path: X-Original-To: netconf-archive@lists.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 D287C3A6A24; Tue, 22 Jul 2008 10:39:59 -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 83C873A6991 for ; Tue, 22 Jul 2008 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599] 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 7CaKnW+CF1x0 for ; Tue, 22 Jul 2008 10:39:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 1DF943A6A14 for ; Tue, 22 Jul 2008 10:39:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6MHeYB3026055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jul 2008 19:40:34 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6MHeYWZ023179; Tue, 22 Jul 2008 19:40:34 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.103]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 19:40:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 19:40:33 +0200 Message-ID: In-Reply-To: <48860FAF.2060300@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netconf-partial-lock-02.txt Thread-Index: AcjsGC1edZVyOxmdQvKZ+YOiNpPUdQAAoV1Q References: <48860FAF.2060300@ericsson.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Balazs Lengyel" X-OriginalArrivalTime: 22 Jul 2008 17:40:34.0204 (UTC) FILETIME=[0B42F5C0:01C8EC22] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16048.000 X-TM-AS-Result: No--7.177700-8.000000-31 Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-partial-lock-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Balazs, we will discuss on WGLC during the NETCONF session. > > - "The system MUST ensure . . ." > > > > I don't know how to ensure this if it is a non-NETCONF management system. > > The statement sounds like a normative statement but it does not cover > > any standard-relevant definition. It is actually a generic statement and > > I would suggest to find another formulation than "MUST". > {BALAZS}: I am not sure I understand your comment. The system > (the netconf server) IS a NETCONF > system, otherwise it would not implement Netconf partial locking. I see this as a requirement > on the Netconf server, not just a generic statement hink MUST is appropriate. > RFC4741 uses MUST when describing global lock "the server > MUST prevent any changes to the locked resource". > Earlier I had "The system ensures" but someone had a comment > to use MUST. I still think that this is a "generic MUST". Anyway I can live with it. > > - I would suggest to indicate that the the "portion of the data store" is a > > "coherent set of nodes". > {BALAZS}: Sorry what do you mean by COHERENT set of nodes? > Could you explain it please. > The set of nodes can consist of 10 disconnected individual > nodes/subtrees if the XPATH expressions are specified that way. I think "a portion of the data store" does not sound very precise. I would suggest to state what you write above, i.e. what we are talking about is possibly "a list of portions" or better "a list of (coherent) set of nodes". > > - 6th paragraph: "If a top level node of a locked subtree > is deleted, . > > . ." > > > > Why is it necessary to keep the lock with a "nil scope" present? > > I would expect that a lock with a nil scope is not needed > and should not > > be kept. > {BALAZS}: It is not nice if a lock just disappears. If the > manager SW later comes and tries to > unlock it and gets back an error he might be surprised. At > this point the manager will need > extra checks to see, whether the error was caused by a > removed empty lock or other error. > But if the workgroup insists this could be changed. OK. What do others think? > > - 2nd bullet: " o Any part of the scope to be locked is > already locked > > . . ." > > > > I think we should have a note here to explain why we think that a partial > > lock can be also introduced by a non-NETCONF management system and > > how this could be realized. > > I agree with an earlier comment that Netconf locking (both global and partial) > > is creating new requirements for SNMP and other protocols. I would propose > > to explain the impact on other management protocols in this note. > {BALAZS}: I need to think about this comment a bit. > The new requirement is not really on the other protocol > handlers, but the instrumentation > behind the protocols. It needs to respect the Netconf > partial-lock which is stated in 2.1 paragraph 2. > If the other protocols also want to use their own > partial-locking, that is their own decision > but that is not a _requirement_ for implementors of this > draft. The other protocols can still use a global lock. I guess we need to state that if a partial lock is executed by a non-NETCONF management system then this system has to follow the rules defined in this document. There might be other impacts on non-NETCONF management protocols, which needs further discussion. Cheers, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf so I think MUST is appropriate. > RFC4741 uses MUST when describing global lock "the server > MUST prevent any changes to the locked resource". > Earlier I had "The system ensures" but someone had a comment > to use MUST. I still think that this is a "generic MUST". Anyway I can live with it. > > - I would suggest to indicate that the the "portion of the data store" is a > > "coherent set of nodes". > {BALAZS}: Sorry what do you mean by COHERENT set of nodes? > Could you explain it please. > The set of nodes can consist of 10 disconnected individual > nodes/subtrees if the XPATH expressions are specified that way. I think "a portion of the data store" does not sound very precise. I would suggest to state what you write above, i.e. what we are talking about is possibly "a list of portions" or better "a list of (coherent) set of nodes". > > - 6th paragraph: "If a top level node of a locked subtree > is deleted, . > > . ." > > > > Why is it necessary to keep the lock with a "nil scope" present? > > I would expect that a lock with a nil scope is not needed > and should not > > be kept. > {BALAZS}: It is not nice if a lock just disappears. If the > manager SW later comes and tries to > unlock it and gets back an error he might be surprised. At > this point the manager will need > extra checks to see, whether the error was caused by a > removed empty lock or other error. > But if the workgroup insists this could be changed. OK. What do others think? > > - 2nd bullet: " o Any part of the scope to be locked is > already locked > > . . ." > > > > I think we should have a note here to explain why we think that a partial > > lock can be also introduced by a non-NETCONF management system and > > how this could be realized. > > I agree with an earlier comment that Netconf locking (both global and partial) > > is creating new requirements for SNMP and other protocols. I would propose > > to explain the impact on other management protocols in this note. > {BALAZS}: I need to think about this comment a bit. > The new requirement is not really on the other protocol > handlers, but the instrumentation > behind the protocols. It needs to respect the Netconf > partial-lock which is stated in 2.1 paragraph 2. > If the other protocols also want to use their own > partial-locking, that is their own decision > but that is not a _requirement_ for implementors of this > draft. The other protocols can still use a global lock. I guess we need to state that if a partial lock is executed by a non-NETCONF management system then this system has to follow the rules defined in this document. There might be other impacts on non-NETCONF management protocols, which needs further discussion. Cheers, Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 10:41:40 2008 Return-Path: X-Original-To: netconf-archive@lists.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 3FE6B3A6A14; Tue, 22 Jul 2008 10:41:40 -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 7D3D43A6A14 for ; Tue, 22 Jul 2008 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 R+CwenGV5UGD for ; Tue, 22 Jul 2008 10:41:37 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 6DD063A69C8 for ; Tue, 22 Jul 2008 10:41:35 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 10:41:11 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6MHfau20615; Tue, 22 Jul 2008 10:41:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MHcaT5030928; Tue, 22 Jul 2008 17:38:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807221738.m6MHcaT5030928@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> Date: Tue, 22 Jul 2008 13:38:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 17:41:36.0681 (UTC) FILETIME=[30803190:01C8EC22] Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: "Balazs Lengyel" writes: >>2.1.1. capabilities >>From RFC4741: "The device uses capabilities to announce the set of data models >>that the device implements." >>This to me means that the device MUST advertise all it's models as capabilities >>as well. So the models will be included both in the capabilities and the >>schemas branch. Please indicate this. > >Experience has shown that was a not the best way to get data model >definitions. I don't think we need to repeat that advise here. We may >want to remove it in an update to RFC4741. This is a bit shocking. Can you give some details about this experience? I've had no problems with it. Was this discussed on the mailing list earlier? Can you give a pointer please? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 10:41:40 2008 Return-Path: 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 3FE6B3A6A14; Tue, 22 Jul 2008 10:41:40 -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 7D3D43A6A14 for ; Tue, 22 Jul 2008 10:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 R+CwenGV5UGD for ; Tue, 22 Jul 2008 10:41:37 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 6DD063A69C8 for ; Tue, 22 Jul 2008 10:41:35 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Tue, 22 Jul 2008 10:41:11 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:37 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:37 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 10:41:36 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6MHfau20615; Tue, 22 Jul 2008 10:41:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m6MHcaT5030928; Tue, 22 Jul 2008 17:38:37 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200807221738.m6MHcaT5030928@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> Date: Tue, 22 Jul 2008 13:38:36 -0400 From: Phil Shafer X-OriginalArrivalTime: 22 Jul 2008 17:41:36.0681 (UTC) FILETIME=[30803190:01C8EC22] Cc: netconf mailing list Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: "Balazs Lengyel" writes: >>2.1.1. capabilities >>From RFC4741: "The device uses capabilities to announce the set of data models >>that the device implements." >>This to me means that the device MUST advertise all it's models as capabilities >>as well. So the models will be included both in the capabilities and the >>schemas branch. Please indicate this. > >Experience has shown that was a not the best way to get data model >definitions. I don't think we need to repeat that advise here. We may >want to remove it in an update to RFC4741. This is a bit shocking. Can you give some details about this experience? I've had no problems with it. Was this discussed on the mailing list earlier? Can you give a pointer please? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 13:51:10 2008 Return-Path: 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 F243D3A6A16; Tue, 22 Jul 2008 13:51:09 -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 D085A3A67D4 for ; Tue, 22 Jul 2008 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] 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 BgS9lw18IKOo for ; Tue, 22 Jul 2008 13:51:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F2F733A6A4F for ; Tue, 22 Jul 2008 13:51:07 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 3684E76C229; Tue, 22 Jul 2008 22:51:49 +0200 (CEST) Date: Tue, 22 Jul 2008 22:51:44 +0200 (CEST) Message-Id: <20080722.225144.62160430.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48861909.8030204@ericsson.com> References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Sharon Chisholm wrote: > > 5.2 int:host schema > > This should be a separate draft as many other will need it. Is > > there today no XML schema for such basic stuff? Can we refer to > > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > > Anyone who cares about XSD should start pushing that draft! > > > We looked at that and either it didn't meet our needs or there was > > a namespace issue, either way, we couldn't use it. In general, if we > > can get better data types by not deriving them from legacy > > definitions then we should not be afraid to do that. I agree though > > that this should be a separate document.. > > > {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so > it can not be legacy. Also Bob Natale indicated to me that he > intends to go on working on it, so join forces. If I understand the intention of draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to provide a direct XSD version of SMI data types. No nice-to-have types will be defined by this spec. For this particular type (inet:host), the best SMIv2 type we can use is InetAddress from rfc 4001, but we can do better in XML (see e.g. inet-types.yang :). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 13:51:10 2008 Return-Path: X-Original-To: netconf-archive@lists.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 F243D3A6A16; Tue, 22 Jul 2008 13:51:09 -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 D085A3A67D4 for ; Tue, 22 Jul 2008 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6] 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 BgS9lw18IKOo for ; Tue, 22 Jul 2008 13:51:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id F2F733A6A4F for ; Tue, 22 Jul 2008 13:51:07 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 3684E76C229; Tue, 22 Jul 2008 22:51:49 +0200 (CEST) Date: Tue, 22 Jul 2008 22:51:44 +0200 (CEST) Message-Id: <20080722.225144.62160430.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48861909.8030204@ericsson.com> References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Sharon Chisholm wrote: > > 5.2 int:host schema > > This should be a separate draft as many other will need it. Is > > there today no XML schema for such basic stuff? Can we refer to > > draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? > > Anyone who cares about XSD should start pushing that draft! > > > We looked at that and either it didn't meet our needs or there was > > a namespace issue, either way, we couldn't use it. In general, if we > > can get better data types by not deriving them from legacy > > definitions then we should not be afraid to do that. I agree though > > that this should be a separate document.. > > > {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so > it can not be legacy. Also Bob Natale indicated to me that he > intends to go on working on it, so join forces. If I understand the intention of draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to provide a direct XSD version of SMI data types. No nice-to-have types will be defined by this spec. For this particular type (inet:host), the best SMIv2 type we can use is InetAddress from rfc 4001, but we can do better in XML (see e.g. inet-types.yang :). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 13:54:23 2008 Return-Path: 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 7AD893A691F; Tue, 22 Jul 2008 13:54:23 -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 ADA533A6882 for ; Tue, 22 Jul 2008 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 f4kKD8tH+qNt for ; Tue, 22 Jul 2008 13:54:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C091C3A67D4 for ; Tue, 22 Jul 2008 13:54:20 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54B3F2043F; Tue, 22 Jul 2008 22:55:01 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-e3-48864925d7fc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3AAF320425; Tue, 22 Jul 2008 22:55:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:55:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:55:00 +0200 Message-ID: <48864924.8040307@ericsson.com> Date: Tue, 22 Jul 2008 22:55:00 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> <20080722.225144.62160430.mbj@tail-f.com> In-Reply-To: <20080722.225144.62160430.mbj@tail-f.com> X-OriginalArrivalTime: 22 Jul 2008 20:55:00.0699 (UTC) FILETIME=[3508D2B0:01C8EC3D] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Should we ask Bob to change his aim? Both Netconf monitoring and DSDL will need the XSD types. Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Sharon Chisholm wrote: >>> 5.2 int:host schema >>> This should be a separate draft as many other will need it. Is >>> there today no XML schema for such basic stuff? Can we refer to >>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>> Anyone who cares about XSD should start pushing that draft! >> >>> We looked at that and either it didn't meet our needs or there was >>> a namespace issue, either way, we couldn't use it. In general, if we >>> can get better data types by not deriving them from legacy >>> definitions then we should not be afraid to do that. I agree though >>> that this should be a separate document.. >>> >> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >> it can not be legacy. Also Bob Natale indicated to me that he >> intends to go on working on it, so join forces. > > If I understand the intention of > draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to > provide a direct XSD version of SMI data types. No nice-to-have types > will be defined by this spec. > > For this particular type (inet:host), the best SMIv2 type we can use > is InetAddress from rfc 4001, but we can do better in XML (see e.g. > inet-types.yang :). > > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 13:54:23 2008 Return-Path: X-Original-To: netconf-archive@lists.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 7AD893A691F; Tue, 22 Jul 2008 13:54:23 -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 ADA533A6882 for ; Tue, 22 Jul 2008 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 f4kKD8tH+qNt for ; Tue, 22 Jul 2008 13:54:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C091C3A67D4 for ; Tue, 22 Jul 2008 13:54:20 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54B3F2043F; Tue, 22 Jul 2008 22:55:01 +0200 (CEST) X-AuditID: c1b4fb3e-ac194bb000004ec0-e3-48864925d7fc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3AAF320425; Tue, 22 Jul 2008 22:55:01 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:55:01 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 22:55:00 +0200 Message-ID: <48864924.8040307@ericsson.com> Date: Tue, 22 Jul 2008 22:55:00 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com> <20080722.225144.62160430.mbj@tail-f.com> In-Reply-To: <20080722.225144.62160430.mbj@tail-f.com> X-OriginalArrivalTime: 22 Jul 2008 20:55:00.0699 (UTC) FILETIME=[3508D2B0:01C8EC3D] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Should we ask Bob to change his aim? Both Netconf monitoring and DSDL will need the XSD types. Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Sharon Chisholm wrote: >>> 5.2 int:host schema >>> This should be a separate draft as many other will need it. Is >>> there today no XML schema for such basic stuff? Can we refer to >>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>> Anyone who cares about XSD should start pushing that draft! >> >>> We looked at that and either it didn't meet our needs or there was >>> a namespace issue, either way, we couldn't use it. In general, if we >>> can get better data types by not deriving them from legacy >>> definitions then we should not be afraid to do that. I agree though >>> that this should be a separate document.. >>> >> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >> it can not be legacy. Also Bob Natale indicated to me that he >> intends to go on working on it, so join forces. > > If I understand the intention of > draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to > provide a direct XSD version of SMI data types. No nice-to-have types > will be defined by this spec. > > For this particular type (inet:host), the best SMIv2 type we can use > is InetAddress from rfc 4001, but we can do better in XML (see e.g. > inet-types.yang :). > > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 22 14:42:47 2008 Return-Path: X-Original-To: netconf-archive@lists.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 7A74E3A6818; Tue, 22 Jul 2008 14:42:47 -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 4D2453A685D for ; Tue, 22 Jul 2008 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 ruxJZ-kJFCAs for ; Tue, 22 Jul 2008 14:42:45 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2EA363A6818 for ; Tue, 22 Jul 2008 14:42:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6MLhPqO001165 for ; Tue, 22 Jul 2008 17:43:26 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6MLhPqr001146; Tue, 22 Jul 2008 17:43:25 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:43:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:42:46 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> In-Reply-To: <48864924.8040307@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjsPTqK38nOnrQ2TQqO0298T4GWBAABXvtQ References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> From: "Natale, Bob" To: "Balazs Lengyel" , "Martin Bjorklund" X-OriginalArrivalTime: 22 Jul 2008 21:43:25.0295 (UTC) FILETIME=[F84EFFF0:01C8EC43] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Balazs, Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd exactly right -- I really don't see any prospect of a change in the purpose of that document (now at -02 and I'm hoping very close to being ready for WGLC). Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely be of the same nature -- as faithful as possible of a direct representations of the major TCs we have defined for SNMP, using the same set of requirements (suitably adjusted where necessary) defined for the base SMI datatypes. Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more creativity in terms of representing MIB structure in XSD, although I believe our plan (led by Dave Harrington)From netconf-bounces@ietf.org Tue Jul 22 14:42:47 2008 Return-Path: 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 7A74E3A6818; Tue, 22 Jul 2008 14:42:47 -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 4D2453A685D for ; Tue, 22 Jul 2008 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 ruxJZ-kJFCAs for ; Tue, 22 Jul 2008 14:42:45 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2EA363A6818 for ; Tue, 22 Jul 2008 14:42:44 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6MLhPqO001165 for ; Tue, 22 Jul 2008 17:43:26 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6MLhPqr001146; Tue, 22 Jul 2008 17:43:25 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:43:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:42:46 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> In-Reply-To: <48864924.8040307@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjsPTqK38nOnrQ2TQqO0298T4GWBAABXvtQ References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> From: "Natale, Bob" To: "Balazs Lengyel" , "Martin Bjorklund" X-OriginalArrivalTime: 22 Jul 2008 21:43:25.0295 (UTC) FILETIME=[F84EFFF0:01C8EC43] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Balazs, Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd exactly right -- I really don't see any prospect of a change in the purpose of that document (now at -02 and I'm hoping very close to being ready for WGLC). Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely be of the same nature -- as faithful as possible of a direct representations of the major TCs we have defined for SNMP, using the same set of requirements (suitably adjusted where necessary) defined for the base SMI datatypes. Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more creativity in terms of representing MIB structure in XSD, although I believe our plan (led by Dave Harrington) is avoid unnecessary incompatibilities with libsmi. (I've used tentative titles on the last two documents wrt OPSAWG sponsorship, anticipating that the pattern there will follow from the base datatypes document.) Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Tuesday, July 22, 2008 4:55 PM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Should we ask Bob to change his aim? Both Netconf monitoring and DSDL will need the XSD types. Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Sharon Chisholm wrote: >>> 5.2 int:host schema >>> This should be a separate draft as many other will need it. Is >>> there today no XML schema for such basic stuff? Can we refer to >>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>> Anyone who cares about XSD should start pushing that draft! >> >>> We looked at that and either it didn't meet our needs or there was >>> a namespace issue, either way, we couldn't use it. In general, if we >>> can get better data types by not deriving them from legacy >>> definitions then we should not be afraid to do that. I agree though >>> that this should be a separate document.. >>> >> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >> it can not be legacy. Also Bob Natale indicated to me that he >> intends to go on working on it, so join forces. > > If I understand the intention of > draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to > provide a direct XSD version of SMI data types. No nice-to-have types > will be defined by this spec. > > For this particular type (inet:host), the best SMIv2 type we can use > is InetAddress from rfc 4001, but we can do better in XML (see e.g. > inet-types.yang :). > > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ 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 is avoid unnecessary incompatibilities with libsmi. (I've used tentative titles on the last two documents wrt OPSAWG sponsorship, anticipating that the pattern there will follow from the base datatypes document.) Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel Sent: Tuesday, July 22, 2008 4:55 PM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Should we ask Bob to change his aim? Both Netconf monitoring and DSDL will need the XSD types. Balazs Martin Bjorklund wrote: > Balazs Lengyel wrote: >> >> Sharon Chisholm wrote: >>> 5.2 int:host schema >>> This should be a separate draft as many other will need it. Is >>> there today no XML schema for such basic stuff? Can we refer to >>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>> Anyone who cares about XSD should start pushing that draft! >> >>> We looked at that and either it didn't meet our needs or there was >>> a namespace issue, either way, we couldn't use it. In general, if we >>> can get better data types by not deriving them from legacy >>> definitions then we should not be afraid to do that. I agree though >>> that this should be a separate document.. >>> >> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >> it can not be legacy. Also Bob Natale indicated to me that he >> intends to go on working on it, so join forces. > > If I understand the intention of > draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to > provide a direct XSD version of SMI data types. No nice-to-have types > will be defined by this spec. > > For this particular type (inet:host), the best SMIv2 type we can use > is InetAddress from rfc 4001, but we can do better in XML (see e.g. > inet-types.yang :). > > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 23 01:38:43 2008 Return-Path: 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 7EE693A6ACD; Wed, 23 Jul 2008 01:38:43 -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 1D4093A6ACD for ; Wed, 23 Jul 2008 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 s5dkQTyJMsvi for ; Wed, 23 Jul 2008 01:38:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D9A483A6AAA for ; Wed, 23 Jul 2008 01:38:40 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0577620665; Wed, 23 Jul 2008 10:39:22 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-e5-4886ee39207d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC73921107; Wed, 23 Jul 2008 10:39:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:39:21 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:39:20 +0200 Message-ID: <4886EE38.3090201@ericsson.com> Date: Wed, 23 Jul 2008 10:39:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Natale, Bob" , Dan Romascanu References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> X-OriginalArrivalTime: 23 Jul 2008 08:39:20.0971 (UTC) FILETIME=[9A1E95B0:01C8EC9F] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bob, Dan, Sorry to spoil your plan, but I see it as a bad thing that we will end up with two slightly incompatible set of XSD types. One coming directly from SMI/SNMP and another related to the Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by separating the Monitoring and the DSDL data types ? It would be fun :-) Dan whats your opinion about the issue? Balazs Natale, Bob wrote: > Hi Balazs, > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > exactly right -- I really don't see any prospect of a change in the > purpose of that document (now at -02 and I'm hoping very close to being > ready for WGLC). > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely > be of the same nature -- as faithful as possible of a direct > representations of the major TCs we have defined for SNMP, using the > same set of requirements (suitably adjusted where necessary) defined > for the base SMI datatypes. > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more > creativity in terms of representing MIB structure in XSD, although I > believe our plan (led by Dave Harrington) is avoid unnecessary > incompatibilities with libsmi. > > (I've used tentative titles on the last two documents wrt OPSAWG > sponsorship, anticipating that the pattern there will follow from the > base datatypes document.) > > Cheers, > BobN > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Balazs Lengyel > Sent: Tuesday, July 22, 2008 4:55 PM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Should we ask Bob to change his aim? Both Netconf monitoring and DSDL > will need the XSD types. > Balazs > > Martin Bjorklund wrote: >> Balazs Lengyel wrote: >>> Sharon Chisholm wrote: >>>> 5.2 int:host schema >>>> This should be a separate draft as many other will need it. Is >>>> there today no XML schema for such basic stuff? Can we refer to >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>>> Anyone who cares about XSD should start pushing that draft! >>> >>>> We looked at that and either it didn't meet our needs or there was >>>> a namespace issue, either way, we couldn't use it. In general, if > we >>>> can get better data types by not deriving them from legacy >>>> definitions then we should not be afraid to do that. I agree though >>>> that this should be a separate document.. >>>> >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >>> it can not be legacy. Also Bob Natale indicated to me that he >>> intends to go on working on it, so join forces. >> If I understand the intention of >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to >> provide a direct XSD version of SMI data types. No nice-to-have > types >> will be defined by this spec. >> >> For this particular type (inet:host), the best SMIv2 type we can use >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. >> inet-types.yang :). >> >> >> /martin > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 01:38:43 2008 Return-Path: X-Original-To: netconf-archive@lists.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 7EE693A6ACD; Wed, 23 Jul 2008 01:38:43 -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 1D4093A6ACD for ; Wed, 23 Jul 2008 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, 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 s5dkQTyJMsvi for ; Wed, 23 Jul 2008 01:38:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D9A483A6AAA for ; Wed, 23 Jul 2008 01:38:40 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0577620665; Wed, 23 Jul 2008 10:39:22 +0200 (CEST) X-AuditID: c1b4fb3e-ad997bb000004ec0-e5-4886ee39207d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC73921107; Wed, 23 Jul 2008 10:39:21 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:39:21 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 10:39:20 +0200 Message-ID: <4886EE38.3090201@ericsson.com> Date: Wed, 23 Jul 2008 10:39:20 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Natale, Bob" , Dan Romascanu References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> X-OriginalArrivalTime: 23 Jul 2008 08:39:20.0971 (UTC) FILETIME=[9A1E95B0:01C8EC9F] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bob, Dan, Sorry to spoil your plan, but I see it as a bad thing that we will end up with two slightly incompatible set of XSD types. One coming directly from SMI/SNMP and another related to the Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by separating the Monitoring and the DSDL data types ? It would be fun :-) Dan whats your opinion about the issue? Balazs Natale, Bob wrote: > Hi Balazs, > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > exactly right -- I really don't see any prospect of a change in the > purpose of that document (now at -02 and I'm hoping very close to being > ready for WGLC). > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd will likely > be of the same nature -- as faithful as possible of a direct > representations of the major TCs we have defined for SNMP, using the > same set of requirements (suitably adjusted where necessary) defined > for the base SMI datatypes. > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow for more > creativity in terms of representing MIB structure in XSD, although I > believe our plan (led by Dave Harrington) is avoid unnecessary > incompatibilities with libsmi. > > (I've used tentative titles on the last two documents wrt OPSAWG > sponsorship, anticipating that the pattern there will follow from the > base datatypes document.) > > Cheers, > BobN > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Balazs Lengyel > Sent: Tuesday, July 22, 2008 4:55 PM > To: Martin Bjorklund > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Should we ask Bob to change his aim? Both Netconf monitoring and DSDL > will need the XSD types. > Balazs > > Martin Bjorklund wrote: >> Balazs Lengyel wrote: >>> Sharon Chisholm wrote: >>>> 5.2 int:host schema >>>> This should be a separate draft as many other will need it. Is >>>> there today no XML schema for such basic stuff? Can we refer to >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the state of that? >>>> Anyone who cares about XSD should start pushing that draft! >>> >>>> We looked at that and either it didn't meet our needs or there was >>>> a namespace issue, either way, we couldn't use it. In general, if > we >>>> can get better data types by not deriving them from legacy >>>> definitions then we should not be afraid to do that. I agree though >>>> that this should be a separate document.. >>>> >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not yet ready so >>> it can not be legacy. Also Bob Natale indicated to me that he >>> intends to go on working on it, so join forces. >> If I understand the intention of >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is supposed to >> provide a direct XSD version of SMI data types. No nice-to-have > types >> will be defined by this spec. >> >> For this particular type (inet:host), the best SMIv2 type we can use >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. >> inet-types.yang :). >> >> >> /martin > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:08:19 2008 Return-Path: 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 30BDB28C1A5; Wed, 23 Jul 2008 02:08:19 -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 C08D928C1A6 for ; Wed, 23 Jul 2008 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 q8UFbCWS6KzS for ; Wed, 23 Jul 2008 02:08:16 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C43DF28C1A2 for ; Wed, 23 Jul 2008 02:08:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="136538174" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 23 Jul 2008 05:08:58 -0400 X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="240899389" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jul 2008 05:08:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:08:52 +0200 Message-ID: In-Reply-To: <4886EE38.3090201@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjsn5z6UVCA/vqvS2CrbJUe8Po1SAAA8ARg References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Natale, Bob" Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs, I do not have a strong opinion (yet). I need to hear more arguments one side and the other of the dispute between the direct translation of existing SMI types and the 'we can do better in XML' version. Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Wednesday, July 23, 2008 11:39 AM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello Bob, Dan, > Sorry to spoil your plan, but I see it as a bad thing that we > will end up with two slightly incompatible set of XSD types. > One coming directly from SMI/SNMP and another related to the > Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by > separating the Monitoring and the DSDL data types ? It would > be fun :-) > > Dan whats your opinion about the issue? > > Balazs > > Natale, Bob wrote: > > Hi Balazs, > > > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > > exactly right -- I really don't see any prospect of a change in the > > purpose of that document (now at -02 and I'm hoping very close to > > being ready for WGLC). > > > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd > will likely > > be of the same nature -- as faithful as possible of a direct > > representations of the major TCs we have defined for SNMP, > using the > > same set of requirements (suitably adjusted where > necessary) defined > > for the base SMI datatypes. > > > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow > for more > > creativity in terms of representing MIB structure in XSD, > although I > > believe our plan (led by Dave Harrington) is avoid unnecessary > > incompatibilities with libsmi. > > > > (I've used tentative titles on the last two documents wrt OPSAWG > > sponsorship, anticipating that the pattern there will > follow from the > > base datatypes document.) > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Balazs Lengyel > > Sent: Tuesday, July 22, 2008 4:55 PM > > To: Martin Bjorklund > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > Should we ask Bob to change his aim? Both Netconf > monitoring and DSDL > > will need the XSD types. > > Balazs > > > > Martin Bjorklund wrote: > >> Balazs Lengyel wrote: > >>> Sharon Chisholm wrote: > >>>> 5.2 int:host schema > >>>> This should be a separate draft as many other will need it. Is > >>>> there today no XML schema for such basic stuff? Can we refer to > >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the > state of that? > >>>> Anyone who cares about XSD should start pushing that draft! > >>> > >>>> We looked at that and either it didn't meet our needs or > there was > >>>> a namespace issue, either way, we couldn't use it. In general, if > > we > >>>> can get better data types by not deriving them from legacy > >>>> definitions then we should not be afraid to do that. I > agree though > >>>> that this should be a separate document.. > >>>> > >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not > yet ready so > >>> it can not be legacy. Also Bob Natale indicated to me that he > >>> intends to go on working on it, so join forces. > >> If I understand the intention of > >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is > supposed to > >> provide a direct XSD version of SMI data types. No nice-to-have > > types > >> will be defined by this spec. > >> > >> For this particular type (inet:host), the best SMIv2 type > we can use > >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. > >> inet-types.yang :). > >> > >> > >> /martin > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:08:19 2008 Return-Path: X-Original-To: netconf-archive@lists.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 30BDB28C1A5; Wed, 23 Jul 2008 02:08:19 -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 C08D928C1A6 for ; Wed, 23 Jul 2008 02:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 q8UFbCWS6KzS for ; Wed, 23 Jul 2008 02:08:16 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C43DF28C1A2 for ; Wed, 23 Jul 2008 02:08:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="136538174" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 23 Jul 2008 05:08:58 -0400 X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="240899389" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jul 2008 05:08:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:08:52 +0200 Message-ID: In-Reply-To: <4886EE38.3090201@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjsn5z6UVCA/vqvS2CrbJUe8Po1SAAA8ARg References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> From: "Romascanu, Dan (Dan)" To: "Balazs Lengyel" , "Natale, Bob" Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs, I do not have a strong opinion (yet). I need to hear more arguments one side and the other of the dispute between the direct translation of existing SMI types and the 'we can do better in XML' version. Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Wednesday, July 23, 2008 11:39 AM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello Bob, Dan, > Sorry to spoil your plan, but I see it as a bad thing that we > will end up with two slightly incompatible set of XSD types. > One coming directly from SMI/SNMP and another related to the > Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by > separating the Monitoring and the DSDL data types ? It would > be fun :-) > > Dan whats your opinion about the issue? > > Balazs > > Natale, Bob wrote: > > Hi Balazs, > > > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > > exactly right -- I really don't see any prospect of a change in the > > purpose of that document (now at -02 and I'm hoping very close to > > being ready for WGLC). > > > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd > will likely > > be of the same nature -- as faithful as possible of a direct > > representations of the major TCs we have defined for SNMP, > using the > > same set of requirements (suitably adjusted where > necessary) defined > > for the base SMI datatypes. > > > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow > for more > > creativity in terms of representing MIB structure in XSD, > although I > > believe our plan (led by Dave Harrington) is avoid unnecessary > > incompatibilities with libsmi. > > > > (I've used tentative titles on the last two documents wrt OPSAWG > > sponsorship, anticipating that the pattern there will > follow from the > > base datatypes document.) > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Balazs Lengyel > > Sent: Tuesday, July 22, 2008 4:55 PM > > To: Martin Bjorklund > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > Should we ask Bob to change his aim? Both Netconf > monitoring and DSDL > > will need the XSD types. > > Balazs > > > > Martin Bjorklund wrote: > >> Balazs Lengyel wrote: > >>> Sharon Chisholm wrote: > >>>> 5.2 int:host schema > >>>> This should be a separate draft as many other will need it. Is > >>>> there today no XML schema for such basic stuff? Can we refer to > >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the > state of that? > >>>> Anyone who cares about XSD should start pushing that draft! > >>> > >>>> We looked at that and either it didn't meet our needs or > there was > >>>> a namespace issue, either way, we couldn't use it. In general, if > > we > >>>> can get better data types by not deriving them from legacy > >>>> definitions then we should not be afraid to do that. I > agree though > >>>> that this should be a separate document.. > >>>> > >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not > yet ready so > >>> it can not be legacy. Also Bob Natale indicated to me that he > >>> intends to go on working on it, so join forces. > >> If I understand the intention of > >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is > supposed to > >> provide a direct XSD version of SMI data types. No nice-to-have > > types > >> will be defined by this spec. > >> > >> For this particular type (inet:host), the best SMIv2 type > we can use > >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. > >> inet-types.yang :). > >> > >> > >> /martin > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:17:29 2008 Return-Path: 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 D944728C191; Wed, 23 Jul 2008 02:17:29 -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 77D1B28C191 for ; Wed, 23 Jul 2008 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 nUUDo9S9dq1j for ; Wed, 23 Jul 2008 02:17:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3FB083A6AC0 for ; Wed, 23 Jul 2008 02:17:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 464A0C0049; Wed, 23 Jul 2008 11:18:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7Dor8sREQHNt; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C474C0038; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CEC767218A; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Date: Wed, 23 Jul 2008 11:17:59 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080723091759.GD1450@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Balazs Lengyel , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > I do not have a strong opinion (yet). I need to hear more arguments one > side and the other of the dispute between the direct translation of > existing SMI types and the 'we can do better in XML' version. Dan, we will need both. Direct translation is essential to have in order to use SMIv2 definitions in an XML world. However, we need to also look ahead and should not unnecessarily constrain NETCONF configuration models by sticking to limitations imposed by the SMIv2. I don't see a problem in general here - just a challenge to find the right balance and to document properly which say YANG types remain consistent with an SMIv2 equivalent and which ones do not. The more scary part (which I mentioned already several weeks ago) is that we have one group working on SMIv2->XSD translations and another group working on SMIv2->YANG->XSD translations. Despite this being perhaps a waste of resources, if the results of both translation chains are not identical, I believe we are really screwed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:17:29 2008 Return-Path: X-Original-To: netconf-archive@lists.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 D944728C191; Wed, 23 Jul 2008 02:17:29 -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 77D1B28C191 for ; Wed, 23 Jul 2008 02:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 nUUDo9S9dq1j for ; Wed, 23 Jul 2008 02:17:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3FB083A6AC0 for ; Wed, 23 Jul 2008 02:17:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 464A0C0049; Wed, 23 Jul 2008 11:18:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7Dor8sREQHNt; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C474C0038; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CEC767218A; Wed, 23 Jul 2008 11:17:59 +0200 (CEST) Date: Wed, 23 Jul 2008 11:17:59 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080723091759.GD1450@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Balazs Lengyel , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > I do not have a strong opinion (yet). I need to hear more arguments one > side and the other of the dispute between the direct translation of > existing SMI types and the 'we can do better in XML' version. Dan, we will need both. Direct translation is essential to have in order to use SMIv2 definitions in an XML world. However, we need to also look ahead and should not unnecessarily constrain NETCONF configuration models by sticking to limitations imposed by the SMIv2. I don't see a problem in general here - just a challenge to find the right balance and to document properly which say YANG types remain consistent with an SMIv2 equivalent and which ones do not. The more scary part (which I mentioned already several weeks ago) is that we have one group working on SMIv2->XSD translations and another group working on SMIv2->YANG->XSD translations. Despite this being perhaps a waste of resources, if the results of both translation chains are not identical, I believe we are really screwed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:29:34 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1EFAC3A69F0; Wed, 23 Jul 2008 02:29:34 -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 BAC313A6922 for ; Wed, 23 Jul 2008 02:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 3G5ZDdapkME2 for ; Wed, 23 Jul 2008 02:29:32 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D37623A6AC0 for ; Wed, 23 Jul 2008 02:29:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="136540009" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 23 Jul 2008 05:30:14 -0400 X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="240909531" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jul 2008 05:30:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:30:10 +0200 Message-ID: In-Reply-To: <20080723091759.GD1450@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjspQYjwcva8mEkQhunVF3asOqcYQAAV7IQ References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <20080723091759.GD1450@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, July 23, 2008 12:18 PM > To: Romascanu, Dan (Dan) > Cc: Balazs Lengyel; Natale, Bob; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > > > I do not have a strong opinion (yet). I need to hear more arguments > > one side and the other of the dispute between the direct > translation > > of existing SMI types and the 'we can do better in XML' version. > > Dan, > > we will need both. Direct translation is essential to have in > order to use SMIv2 definitions in an XML world. However, we > need to also look ahead and should not unnecessarily > constrain NETCONF configuration models by sticking to > limitations imposed by the SMIv2. I don't see a problem in > general here - just a challenge to find the right balance and > to document properly which say YANG types remain consistent > with an SMIv2 equivalent and which ones do not. > > The more scary part (which I mentioned already several weeks > ago) is that we have one group working on SMIv2->XSD > translations and another group working on SMIv2->YANG->XSD > translations. Despite this being perhaps a waste of > resources, if the results of both translation chains are not > identical, I believe we are really screwed. > > /js > What I am missing probably due to the lack of understanding of the details on my side (hopefully temporary) is whether achieving identical translation is doable, and if yes at what cost. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:29:34 2008 Return-Path: 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 1EFAC3A69F0; Wed, 23 Jul 2008 02:29:34 -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 BAC313A6922 for ; Wed, 23 Jul 2008 02:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 3G5ZDdapkME2 for ; Wed, 23 Jul 2008 02:29:32 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D37623A6AC0 for ; Wed, 23 Jul 2008 02:29:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="136540009" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 23 Jul 2008 05:30:14 -0400 X-IronPort-AV: E=Sophos;i="4.31,237,1215403200"; d="scan'208";a="240909531" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jul 2008 05:30:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:30:10 +0200 Message-ID: In-Reply-To: <20080723091759.GD1450@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjspQYjwcva8mEkQhunVF3asOqcYQAAV7IQ References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <20080723091759.GD1450@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, July 23, 2008 12:18 PM > To: Romascanu, Dan (Dan) > Cc: Balazs Lengyel; Natale, Bob; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > > > I do not have a strong opinion (yet). I need to hear more arguments > > one side and the other of the dispute between the direct > translation > > of existing SMI types and the 'we can do better in XML' version. > > Dan, > > we will need both. Direct translation is essential to have in > order to use SMIv2 definitions in an XML world. However, we > need to also look ahead and should not unnecessarily > constrain NETCONF configuration models by sticking to > limitations imposed by the SMIv2. I don't see a problem in > general here - just a challenge to find the right balance and > to document properly which say YANG types remain consistent > with an SMIv2 equivalent and which ones do not. > > The more scary part (which I mentioned already several weeks > ago) is that we have one group working on SMIv2->XSD > translations and another group working on SMIv2->YANG->XSD > translations. Despite this being perhaps a waste of > resources, if the results of both translation chains are not > identical, I believe we are really screwed. > > /js > What I am missing probably due to the lack of understanding of the details on my side (hopefully temporary) is whether achieving identical translation is doable, and if yes at what cost. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:45:36 2008 Return-Path: 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 811F528C149; Wed, 23 Jul 2008 02:45:36 -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 65B323A6AE9 for ; Wed, 23 Jul 2008 02:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 e5WRSAdpoY3R for ; Wed, 23 Jul 2008 02:45:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6F1D63A6AE6 for ; Wed, 23 Jul 2008 02:45:22 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A48C0046; Wed, 23 Jul 2008 11:46:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 83YeuPnLWpTN; Wed, 23 Jul 2008 11:45:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97CF4C000A; Wed, 23 Jul 2008 11:45:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E5C167233A; Wed, 23 Jul 2008 11:45:58 +0200 (CEST) Date: Wed, 23 Jul 2008 11:45:58 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080723094558.GF1450@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Balazs Lengyel , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <20080723091759.GD1450@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:30:10AM +0200, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, July 23, 2008 12:18 PM > > To: Romascanu, Dan (Dan) > > Cc: Balazs Lengyel; Natale, Bob; netconf@ietf.org > > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > > > On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > > > > > I do not have a strong opinion (yet). I need to hear more arguments > > > one side and the other of the dispute between the direct > > translation > > > of existing SMI types and the 'we can do better in XML' version. > > > > Dan, > > > > we will need both. Direct translation is essential to have in > > order to use SMIv2 definitions in an XML world. However, we > > need to also look ahead and should not unnecessarily > > constrain NETCONF configuration models by sticking to > > limitations imposed by the SMIv2. I don't see a problem in > > general here - just a challenge to find the right balance and > > to document properly which say YANG types remain consistent > > with an SMIv2 equivalent and which ones do not. > > > > The more scary part (which I mentioned already several weeks > > ago) is that we have one group working on SMIv2->XSD > > translations and another group working on SMIv2->YANG->XSD > > translations. Despite this being perhaps a waste of > > resources, if the results of both translation chains are not > > identical, I believe we are really screwed. > > > > /js > > > > What I am missing probably due to the lack of understanding of the > details on my side (hopefully temporary) is whether achieving identical > translation is doable, and if yes at what cost. IETF cost means delay. If we do SMIv2->YANG->XSD, we get SMIv2->XSD for free except that doing both in parallel might be faster (but if you want to have the result consistent, this argument becomes void). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 02:45:36 2008 Return-Path: X-Original-To: netconf-archive@lists.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 811F528C149; Wed, 23 Jul 2008 02:45:36 -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 65B323A6AE9 for ; Wed, 23 Jul 2008 02:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 e5WRSAdpoY3R for ; Wed, 23 Jul 2008 02:45:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6F1D63A6AE6 for ; Wed, 23 Jul 2008 02:45:22 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A48C0046; Wed, 23 Jul 2008 11:46:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 83YeuPnLWpTN; Wed, 23 Jul 2008 11:45:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97CF4C000A; Wed, 23 Jul 2008 11:45:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5E5C167233A; Wed, 23 Jul 2008 11:45:58 +0200 (CEST) Date: Wed, 23 Jul 2008 11:45:58 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080723094558.GF1450@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Balazs Lengyel , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <20080723091759.GD1450@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:30:10AM +0200, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, July 23, 2008 12:18 PM > > To: Romascanu, Dan (Dan) > > Cc: Balazs Lengyel; Natale, Bob; netconf@ietf.org > > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > > > On Wed, Jul 23, 2008 at 11:08:52AM +0200, Romascanu, Dan (Dan) wrote: > > > > > I do not have a strong opinion (yet). I need to hear more arguments > > > one side and the other of the dispute between the direct > > translation > > > of existing SMI types and the 'we can do better in XML' version. > > > > Dan, > > > > we will need both. Direct translation is essential to have in > > order to use SMIv2 definitions in an XML world. However, we > > need to also look ahead and should not unnecessarily > > constrain NETCONF configuration models by sticking to > > limitations imposed by the SMIv2. I don't see a problem in > > general here - just a challenge to find the right balance and > > to document properly which say YANG types remain consistent > > with an SMIv2 equivalent and which ones do not. > > > > The more scary part (which I mentioned already several weeks > > ago) is that we have one group working on SMIv2->XSD > > translations and another group working on SMIv2->YANG->XSD > > translations. Despite this being perhaps a waste of > > resources, if the results of both translation chains are not > > identical, I believe we are really screwed. > > > > /js > > > > What I am missing probably due to the lack of understanding of the > details on my side (hopefully temporary) is whether achieving identical > translation is doable, and if yes at what cost. IETF cost means delay. If we do SMIv2->YANG->XSD, we get SMIv2->XSD for free except that doing both in parallel might be faster (but if you want to have the result consistent, this argument becomes void). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 04:42:28 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1B45A3A69F4; Wed, 23 Jul 2008 04:42:28 -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 6AAE73A69F4 for ; Wed, 23 Jul 2008 04:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 WD+FpX-wksWM for ; Wed, 23 Jul 2008 04:42:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AFC103A6927 for ; Wed, 23 Jul 2008 04:42:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NBh4pO018682 for ; Wed, 23 Jul 2008 07:43:08 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NBh4Wl018671; Wed, 23 Jul 2008 07:43:04 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 07:43:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 07:42:39 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjsn5z6UVCA/vqvS2CrbJUe8Po1SAAA8ARgAAVRRkA= References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> From: "Natale, Bob" To: "Romascanu, Dan (Dan)" , "Balazs Lengyel" X-OriginalArrivalTime: 23 Jul 2008 11:43:04.0174 (UTC) FILETIME=[4475E0E0:01C8ECB9] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Dan, There is a set of potential XML-based management applications -- and a user community that needs them -- that requires maximum compatibility and interoperability with legacy/existing SNMP management applications and managed resources. In that context, these applications -- and their developers and their users -- do not need "anything better" or anything "extra" ... they need as close to the original as possible ... and sooner rather than later. Hence, the "XSDMI" effort -- which continues to strive to avoid gratuitous incompatibilities with the rest of the IETF O&M world, but does claim to have valid requirements for the stated purpose. Rushed, BobN -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, July 23, 2008 5:09 AM To: Balazs Lengyel; Natale, Bob Cc: Martin Bjorklund; netconf@ietf.org Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Balazs, I do not have a strong opinion (yet). I need to hear more arguments one side and the other of the dispute between the direct translation of existing SMI types and the 'we can do better in XML' version. Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Wednesday, July 23, 2008 11:39 AM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello Bob, Dan, > Sorry to spoil your plan, but I see it as a bad thing that we > will end up with two slightly incompatible set of XSD types. > One coming directly from SMI/SNMP and another related to the > Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by > separating the Monitoring and the DSDL data types ? It would > be fun :-) > > Dan whats your opinion about the issue? > > Balazs > > Natale, Bob wrote: > > Hi Balazs, > > > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > > exactly right -- I really don't see any prospect of a change in the > > purpose of that document (now at -02 and I'm hoping very close to > > being ready for WGLC). > > > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd > will likely > > be of the same nature -- as faithful as possible of a direct > > representations of the major TCs we have defined for SNMP, > using the > > same set of requirements (suitably adjusted where > necessary) defined > > for the base SMI datatypes. > > > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow > for more > > creativity in terms of representing MIB structure in XSD, > although I > > believe our plan (led by Dave Harrington) is avoid unnecessary > > incompatibilities with libsmi. > > > > (I've used tentative titles on the last two documents wrt OPSAWG > > sponsorship, anticipating that the pattern there will > follow from the > > base datatypes document.) > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Balazs Lengyel > > Sent: Tuesday, July 22, 2008 4:55 PM > > To: Martin Bjorklund > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > Should we ask Bob to change his aim? Both Netconf > monitoring and DSDL > > will need the XSD types. > > Balazs > > > > Martin Bjorklund wrote: > >> Balazs Lengyel wrote: > >>> Sharon Chisholm wrote: > >>>> 5.2 int:host schema > >>>> This should be a separate draft as many other will need it. Is > >>>> there today no XML schema for such basic stuff? Can we refer to > >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the > state of that? > >>>> Anyone who cares about XSD should start pushing that draft! > >>> > >>>> We looked at that and either it didn't meet our needs or > there was > >>>> a namespace issue, either way, we couldn't use it. In general, if > > we > >>>> can get better data types by not deriving them from legacy > >>>> definitions then we should not be afraid to do that. I > agree though > >>>> that this should be a separate document.. > >>>> > >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not > yet ready so > >>> it can not be legacy. Also Bob Natale indicated to me that he > >>> intends to go on working on it, so join forces. > >> If I understand the intention of > >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is > supposed to > >> provide a direct XSD version of SMI data types. No nice-to-have > > types > >> will be defined by this spec. > >> > >> For this particular type (inet:host), the best SMIv2 type > we can use > >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. > >> inet-types.yang :). > >> > >> > >> /martin > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 04:42:28 2008 Return-Path: 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 1B45A3A69F4; Wed, 23 Jul 2008 04:42:28 -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 6AAE73A69F4 for ; Wed, 23 Jul 2008 04:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 WD+FpX-wksWM for ; Wed, 23 Jul 2008 04:42:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id AFC103A6927 for ; Wed, 23 Jul 2008 04:42:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NBh4pO018682 for ; Wed, 23 Jul 2008 07:43:08 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NBh4Wl018671; Wed, 23 Jul 2008 07:43:04 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 07:43:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 07:42:39 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjsn5z6UVCA/vqvS2CrbJUe8Po1SAAA8ARgAAVRRkA= References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48861909.8030204@ericsson.com><20080722.225144.62160430.mbj@tail-f.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> From: "Natale, Bob" To: "Romascanu, Dan (Dan)" , "Balazs Lengyel" X-OriginalArrivalTime: 23 Jul 2008 11:43:04.0174 (UTC) FILETIME=[4475E0E0:01C8ECB9] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Dan, There is a set of potential XML-based management applications -- and a user community that needs them -- that requires maximum compatibility and interoperability with legacy/existing SNMP management applications and managed resources. In that context, these applications -- and their developers and their users -- do not need "anything better" or anything "extra" ... they need as close to the original as possible ... and sooner rather than later. Hence, the "XSDMI" effort -- which continues to strive to avoid gratuitous incompatibilities with the rest of the IETF O&M world, but does claim to have valid requirements for the stated purpose. Rushed, BobN -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, July 23, 2008 5:09 AM To: Balazs Lengyel; Natale, Bob Cc: Martin Bjorklund; netconf@ietf.org Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Balazs, I do not have a strong opinion (yet). I need to hear more arguments one side and the other of the dispute between the direct translation of existing SMI types and the 'we can do better in XML' version. Dan > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Wednesday, July 23, 2008 11:39 AM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: Martin Bjorklund; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello Bob, Dan, > Sorry to spoil your plan, but I see it as a bad thing that we > will end up with two slightly incompatible set of XSD types. > One coming directly from SMI/SNMP and another related to the > Netmod/DSDL/Netconf Monitoring work. (Could we have 3 sets by > separating the Monitoring and the DSDL data types ? It would > be fun :-) > > Dan whats your opinion about the issue? > > Balazs > > Natale, Bob wrote: > > Hi Balazs, > > > > Martin has the purpose of draft-ietf-opsawg-smi-datatypes-in-xsd > > exactly right -- I really don't see any prospect of a change in the > > purpose of that document (now at -02 and I'm hoping very close to > > being ready for WGLC). > > > > Likewise, draft-ietf-opsawg-smi-textual-conventions-in-xsd > will likely > > be of the same nature -- as faithful as possible of a direct > > representations of the major TCs we have defined for SNMP, > using the > > same set of requirements (suitably adjusted where > necessary) defined > > for the base SMI datatypes. > > > > Finally, draft-ietf-opsawg-smi-structure-in-xsd might allow > for more > > creativity in terms of representing MIB structure in XSD, > although I > > believe our plan (led by Dave Harrington) is avoid unnecessary > > incompatibilities with libsmi. > > > > (I've used tentative titles on the last two documents wrt OPSAWG > > sponsorship, anticipating that the pattern there will > follow from the > > base datatypes document.) > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Balazs Lengyel > > Sent: Tuesday, July 22, 2008 4:55 PM > > To: Martin Bjorklund > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > Should we ask Bob to change his aim? Both Netconf > monitoring and DSDL > > will need the XSD types. > > Balazs > > > > Martin Bjorklund wrote: > >> Balazs Lengyel wrote: > >>> Sharon Chisholm wrote: > >>>> 5.2 int:host schema > >>>> This should be a separate draft as many other will need it. Is > >>>> there today no XML schema for such basic stuff? Can we refer to > >>>> draft-ietf-opsawg-smi-datatypes-in-xsd? What is the > state of that? > >>>> Anyone who cares about XSD should start pushing that draft! > >>> > >>>> We looked at that and either it didn't meet our needs or > there was > >>>> a namespace issue, either way, we couldn't use it. In general, if > > we > >>>> can get better data types by not deriving them from legacy > >>>> definitions then we should not be afraid to do that. I > agree though > >>>> that this should be a separate document.. > >>>> > >>> {BALAZS}: draft-ietf-opsawg-smi-datatypes-in-xsd is not > yet ready so > >>> it can not be legacy. Also Bob Natale indicated to me that he > >>> intends to go on working on it, so join forces. > >> If I understand the intention of > >> draft-ietf-opsawg-smi-datatypes-in-xsd correctly, it is > supposed to > >> provide a direct XSD version of SMI data types. No nice-to-have > > types > >> will be defined by this spec. > >> > >> For this particular type (inet:host), the best SMIv2 type > we can use > >> is InetAddress from rfc 4001, but we can do better in XML (see e.g. > >> inet-types.yang :). > >> > >> > >> /martin > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 05:44:29 2008 Return-Path: X-Original-To: netconf-archive@lists.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 C1C4B28C11A; Wed, 23 Jul 2008 05:44:29 -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 AE68828C11A for ; Wed, 23 Jul 2008 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 rV8j0TtTrS4w for ; Wed, 23 Jul 2008 05:44:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D45F33A6A4A for ; Wed, 23 Jul 2008 05:44:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 465C1C003C; Wed, 23 Jul 2008 14:45:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yt2bEGwvHi9f; Wed, 23 Jul 2008 14:45:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1DEC0038; Wed, 23 Jul 2008 14:45:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7AED6728FE; Wed, 23 Jul 2008 14:45:02 +0200 (CEST) Date: Wed, 23 Jul 2008 14:45:02 +0200 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20080723124502.GA3425@elstar.local> Mail-Followup-To: "Natale, Bob" , "Romascanu, Dan (Dan)" , Balazs Lengyel , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anytFrom netconf-bounces@ietf.org Wed Jul 23 05:44:29 2008 Return-Path: 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 C1C4B28C11A; Wed, 23 Jul 2008 05:44:29 -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 AE68828C11A for ; Wed, 23 Jul 2008 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 rV8j0TtTrS4w for ; Wed, 23 Jul 2008 05:44:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D45F33A6A4A for ; Wed, 23 Jul 2008 05:44:27 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 465C1C003C; Wed, 23 Jul 2008 14:45:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yt2bEGwvHi9f; Wed, 23 Jul 2008 14:45:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C1DEC0038; Wed, 23 Jul 2008 14:45:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C7AED6728FE; Wed, 23 Jul 2008 14:45:02 +0200 (CEST) Date: Wed, 23 Jul 2008 14:45:02 +0200 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20080723124502.GA3425@elstar.local> Mail-Followup-To: "Natale, Bob" , "Romascanu, Dan (Dan)" , Balazs Lengyel , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anything "hing "extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, > but does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, > but does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 06:44:25 2008 Return-Path: X-Original-To: netconf-archive@lists.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 DF40D3A6900; Wed, 23 Jul 2008 06:44:25 -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 2F5B03A6900 for ; Wed, 23 Jul 2008 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 X45e2A+JwaE2 for ; Wed, 23 Jul 2008 06:44:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id AF1723A6881 for ; Wed, 23 Jul 2008 06:44:23 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NDj2S11229; Wed, 23 Jul 2008 13:45:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 09:44:17 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> In-Reply-To: <20080723124502.GA3425@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhA References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> From: "Sharon Chisholm" To: , "Natale, Bob" Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi My view on this topic is that we need high-quality data types. In some cases this is possible while supporting simple translations from SNMP MIBs, but in other cases it will not. In the cases where optimizing for the translation results in sub-optimal data types definitions for use in NETCONF, we need go with the high-quality types. (And no, I don't have a concrete definition of 'high-quality'). In this case, it may be possible to align on a single definition for these items. I believe that Bob's is missing a namespace declaration, so that need to be addressed. I think then the only definition of potential interest from that set was IpAddress, but as defined it I don't think it supports ipV6, or if it does, it doesn't do it with ":" separators. I think the inet:host schema in the monitoring draft has a more complete solution for IP addresses. If we decide we want to merge this work, then it needs to be publiFrom netconf-bounces@ietf.org Wed Jul 23 06:44:25 2008 Return-Path: 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 DF40D3A6900; Wed, 23 Jul 2008 06:44:25 -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 2F5B03A6900 for ; Wed, 23 Jul 2008 06:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 X45e2A+JwaE2 for ; Wed, 23 Jul 2008 06:44:24 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id AF1723A6881 for ; Wed, 23 Jul 2008 06:44:23 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NDj2S11229; Wed, 23 Jul 2008 13:45:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 09:44:17 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> In-Reply-To: <20080723124502.GA3425@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhA References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> From: "Sharon Chisholm" To: , "Natale, Bob" Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi My view on this topic is that we need high-quality data types. In some cases this is possible while supporting simple translations from SNMP MIBs, but in other cases it will not. In the cases where optimizing for the translation results in sub-optimal data types definitions for use in NETCONF, we need go with the high-quality types. (And no, I don't have a concrete definition of 'high-quality'). In this case, it may be possible to align on a single definition for these items. I believe that Bob's is missing a namespace declaration, so that need to be addressed. I think then the only definition of potential interest from that set was IpAddress, but as defined it I don't think it supports ipV6, or if it does, it doesn't do it with ":" separators. I think the inet:host schema in the monitoring draft has a more complete solution for IP addresses. If we decide we want to merge this work, then it needs to be published ished in a specification that isn't SNMP specific. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, July 23, 2008 8:45 AM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anything "extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, but > does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 n a specification that isn't SNMP specific. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, July 23, 2008 8:45 AM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anything "extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, but > does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 23 07:48:58 2008 Return-Path: X-Original-To: netconf-archive@lists.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 CB8233A68E7; Wed, 23 Jul 2008 07:48:58 -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 CD0B03A68E7 for ; Wed, 23 Jul 2008 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6] 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 KZJySQlgcEnL for ; Wed, 23 Jul 2008 07:48:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C153F3A68AA for ; Wed, 23 Jul 2008 07:48:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FDD8C0048; Wed, 23 Jul 2008 16:49:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4P-MMT+246Oq; Wed, 23 Jul 2008 16:49:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61178C0037; Wed, 23 Jul 2008 16:49:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17EF3672E3A; Wed, 23 Jul 2008 16:49:33 +0200 (CEST) Date: Wed, 23 Jul 2008 16:49:32 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080723144932.GC3531@elstar.local> Mail-Followup-To: Sharon Chisholm , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote: > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, so > that need to be addressed. I think then the only definition of potential > interest from that set was IpAddress, but as definedFrom netconf-bounces@ietf.org Wed Jul 23 07:48:58 2008 Return-Path: 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 CB8233A68E7; Wed, 23 Jul 2008 07:48:58 -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 CD0B03A68E7 for ; Wed, 23 Jul 2008 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6] 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 KZJySQlgcEnL for ; Wed, 23 Jul 2008 07:48:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C153F3A68AA for ; Wed, 23 Jul 2008 07:48:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FDD8C0048; Wed, 23 Jul 2008 16:49:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4P-MMT+246Oq; Wed, 23 Jul 2008 16:49:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61178C0037; Wed, 23 Jul 2008 16:49:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17EF3672E3A; Wed, 23 Jul 2008 16:49:33 +0200 (CEST) Date: Wed, 23 Jul 2008 16:49:32 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080723144932.GC3531@elstar.local> Mail-Followup-To: Sharon Chisholm , "Natale, Bob" , netconf@ietf.org References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote: > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, so > that need to be addressed. I think then the only definition of potential > interest from that set was IpAddress, but as defined it I it I don't think it > supports ipV6, or if it does, it doesn't do it with ":" separators. I > think the inet:host schema in the monitoring draft has a more complete > solution for IP addresses. If we decide we want to merge this work, then > it needs to be published in a specification that isn't SNMP specific. So how is inet:host different from what you get out of translating the YANG inet:host definition into XSD? The fact that these things are different is what IMHO a good standardization body needs to avoid. And the approach to constantly align N different definitions does not scale well and is asking for trouble if you ask me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf don't think it > supports ipV6, or if it does, it doesn't do it with ":" separators. I > think the inet:host schema in the monitoring draft has a more complete > solution for IP addresses. If we decide we want to merge this work, then > it needs to be published in a specification that isn't SNMP specific. So how is inet:host different from what you get out of translating the YANG inet:host definition into XSD? The fact that these things are different is what IMHO a good standardization body needs to avoid. And the approach to constantly align N different definitions does not scale well and is asking for trouble if you ask me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 08:17:52 2008 Return-Path: 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 0DEF13A6AE5; Wed, 23 Jul 2008 08:17:52 -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 C58EB3A6ADE for ; Wed, 23 Jul 2008 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 28xP-MgWlJV4 for ; Wed, 23 Jul 2008 08:17:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5634B3A6407 for ; Wed, 23 Jul 2008 08:17:49 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NFISF10746; Wed, 23 Jul 2008 15:18:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:18:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> In-Reply-To: <20080723144932.GC3531@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjs01ggflIRYcYKRdu0e4xgHxpWTwAA1zWw References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> From: "Sharon Chisholm" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Aside from the format of the name, it like looks ipAddress maps reasonably well. We also have a definition for domainName which I don't think is covered in the yang data types. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, July 23, 2008 10:50 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Natale, Bob; netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote: > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, > so that need to be addressed. I think then the only definition of > potential interest from that set was IpAddress, but as defined it I > don't think it supports ipV6, or ifFrom netconf-bounces@ietf.org Wed Jul 23 08:17:52 2008 Return-Path: X-Original-To: netconf-archive@lists.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 0DEF13A6AE5; Wed, 23 Jul 2008 08:17:52 -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 C58EB3A6ADE for ; Wed, 23 Jul 2008 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 28xP-MgWlJV4 for ; Wed, 23 Jul 2008 08:17:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5634B3A6407 for ; Wed, 23 Jul 2008 08:17:49 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6NFISF10746; Wed, 23 Jul 2008 15:18:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 11:18:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> In-Reply-To: <20080723144932.GC3531@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: Acjs01ggflIRYcYKRdu0e4xgHxpWTwAA1zWw References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> From: "Sharon Chisholm" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Aside from the format of the name, it like looks ipAddress maps reasonably well. We also have a definition for domainName which I don't think is covered in the yang data types. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, July 23, 2008 10:50 AM To: Chisholm, Sharon (CAR:ZZ00) Cc: Natale, Bob; netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 09:44:17AM -0400, Sharon Chisholm wrote: > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, > so that need to be addressed. I think then the only definition of > potential interest from that set was IpAddress, but as defined it I > don't think it supports ipV6, it does, it doesn't do it with ":" > separators. I think the inet:host schema in the monitoring draft has a > more complete solution for IP addresses. If we decide we want to merge > this work, then it needs to be published in a specification that isn't SNMP specific. So how is inet:host different from what you get out of translating the YANG inet:host definition into XSD? The fact that these things are different is what IMHO a good standardization body needs to avoid. And the approach to constantly align N different definitions does not scale well and is asking for trouble if you ask me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf or if it does, it doesn't do it with ":" > separators. I think the inet:host schema in the monitoring draft has a > more complete solution for IP addresses. If we decide we want to merge > this work, then it needs to be published in a specification that isn't SNMP specific. So how is inet:host different from what you get out of translating the YANG inet:host definition into XSD? The fact that these things are different is what IMHO a good standardization body needs to avoid. And the approach to constantly align N different definitions does not scale well and is asking for trouble if you ask me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 08:54:50 2008 Return-Path: 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 1BC793A67EE; Wed, 23 Jul 2008 08:54:50 -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 DBFB53A6913 for ; Wed, 23 Jul 2008 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 2D36ADFUZt1S for ; Wed, 23 Jul 2008 08:54:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 980A03A67EE for ; Wed, 23 Jul 2008 08:54:47 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15CEEC000F; Wed, 23 Jul 2008 17:55:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iYwUk8A916RT; Wed, 23 Jul 2008 17:55:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6ABAC0046; Wed, 23 Jul 2008 17:55:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A2D4673168; Wed, 23 Jul 2008 17:55:24 +0200 (CEST) Date: Wed, 23 Jul 2008 17:55:24 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm , Dan Romascanu Message-ID: <20080723155524.GA4295@elstar.local> Mail-Followup-To: Sharon Chisholm , Dan Romascanu , "Natale, Bob" , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:18:20AM -0400, Sharon Chisholm wrote: > Aside from the format of the name, it like looks ipAddress maps > reasonably well. We also have a definition for domainName which I don't > think is coFrom netconf-bounces@ietf.org Wed Jul 23 08:54:50 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1BC793A67EE; Wed, 23 Jul 2008 08:54:50 -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 DBFB53A6913 for ; Wed, 23 Jul 2008 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 2D36ADFUZt1S for ; Wed, 23 Jul 2008 08:54:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 980A03A67EE for ; Wed, 23 Jul 2008 08:54:47 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15CEEC000F; Wed, 23 Jul 2008 17:55:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iYwUk8A916RT; Wed, 23 Jul 2008 17:55:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6ABAC0046; Wed, 23 Jul 2008 17:55:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A2D4673168; Wed, 23 Jul 2008 17:55:24 +0200 (CEST) Date: Wed, 23 Jul 2008 17:55:24 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm , Dan Romascanu Message-ID: <20080723155524.GA4295@elstar.local> Mail-Followup-To: Sharon Chisholm , Dan Romascanu , "Natale, Bob" , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945F50@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 11:18:20AM -0400, Sharon Chisholm wrote: > Aside from the format of the name, it like looks ipAddress maps > reasonably well. We also have a definition for domainName which I don't > think is covered in the yang data types. Well, you seem to ignore all the fancy details such as patterns. Are they really the same? And yes, I think there is something for domain names in inet-types.yang as well: typedef host { type union { type inet:ip-address; type inet:domain-name; } description "The host type represents either an IP address or a DNS domain name."; } If it is already too difficult for authors to find out these rather obvious differences, how can we believe we will ever reach a consistent result? Dan, I believe this simple example is proof enough that the issue is out there and we should take advantage of the face-to-face meeting next week to find a way to address 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf vered in the yang data types. Well, you seem to ignore all the fancy details such as patterns. Are they really the same? And yes, I think there is something for domain names in inet-types.yang as well: typedef host { type union { type inet:ip-address; type inet:domain-name; } description "The host type represents either an IP address or a DNS domain name."; } If it is already too difficult for authors to find out these rather obvious differences, how can we believe we will ever reach a consistent result? Dan, I believe this simple example is proof enough that the issue is out there and we should take advantage of the face-to-face meeting next week to find a way to address 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 10:11:13 2008 Return-Path: X-Original-To: netconf-archive@lists.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 893D73A6818; Wed, 23 Jul 2008 10:11:13 -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 7D1303A6901 for ; Wed, 23 Jul 2008 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 LoSXNXy43Jn1 for ; Wed, 23 Jul 2008 10:11:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 274713A6818 for ; Wed, 23 Jul 2008 10:11:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NHBrgr002178 for ; Wed, 23 Jul 2008 13:11:53 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NHBrZD002173; Wed, 23 Jul 2008 13:11:53 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 13:11:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 13:11:30 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaA= References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> From: "Natale, Bob" To: "Sharon Chisholm" , X-OriginalArrivalTime: 23 Jul 2008 17:11:53.0037 (UTC) FILETIME=[33C777D0:01C8ECE7] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, Thanks for the observations: 1. I will add the namespace definition in an -03 update imminently -- oversight in -02. 2. The SMIv2 (RFC2578) definition of IpAddress is: IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) That is all -- with the associated value restrictions -- XSDMI intends to represent in the base SMI datatypes set. I don't have a view on the need for high-quality data types (sure sounds like a good thing though) -- I'm just concerned in this context with XSD to validate the direct translation of SMI-compliant SNMP data into XML. Cheers, BobN -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortel.com] Sent: Wednesday, July 23, 2008 9:44 AM To: j.schoenwaelder@jacobs-university.de; Natale, Bob Cc: netconf@ietf.org Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Hi My view on this topic is that we need high-quality data types. In some cases this is possible while supporting simple translations from SNMP MIBs, but in other cases it will not. In the cases where optimizing for the translation results in sub-optimal data types definitions for use in NETCONF, we need go with the high-quality types. (And no, I don't have a concrete definition of 'high-quality'). In this case, it may be possible to align on a single definition for these items. I believe that Bob's is missing a namespace declaration, so that need to be addressed. I think then the only definition of potential interest from that set was IpAddress, but as defined it I don't think it supports ipV6, or if it does, it doesn't do it with ":" separators. I think the inet:host schema in the monitoring draft has a more complete solution for IP addresses. If we decide we want to merge this work, then it needs to be published in a specification that isn't SNMP specific. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, July 23, 2008 8:45 AM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anything "extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, but > does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 23 10:11:13 2008 Return-Path: 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 893D73A6818; Wed, 23 Jul 2008 10:11:13 -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 7D1303A6901 for ; Wed, 23 Jul 2008 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 LoSXNXy43Jn1 for ; Wed, 23 Jul 2008 10:11:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 274713A6818 for ; Wed, 23 Jul 2008 10:11:11 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NHBrgr002178 for ; Wed, 23 Jul 2008 13:11:53 -0400 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6NHBrZD002173; Wed, 23 Jul 2008 13:11:53 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 13:11:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 13:11:30 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaA= References: <4885CB51.1000703@ericsson.com> <713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com> <48864924.8040307@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG> <4886EE38.3090201@ericsson.com> <4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG> <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> From: "Natale, Bob" To: "Sharon Chisholm" , X-OriginalArrivalTime: 23 Jul 2008 17:11:53.0037 (UTC) FILETIME=[33C777D0:01C8ECE7] Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, Thanks for the observations: 1. I will add the namespace definition in an -03 update imminently -- oversight in -02. 2. The SMIv2 (RFC2578) definition of IpAddress is: IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) That is all -- with the associated value restrictions -- XSDMI intends to represent in the base SMI datatypes set. I don't have a view on the need for high-quality data types (sure sounds like a good thing though) -- I'm just concerned in this context with XSD to validate the direct translation of SMI-compliant SNMP data into XML. Cheers, BobN -----Original Message----- From: Sharon Chisholm [mailto:schishol@nortel.com] Sent: Wednesday, July 23, 2008 9:44 AM To: j.schoenwaelder@jacobs-university.de; Natale, Bob Cc: netconf@ietf.org Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Hi My view on this topic is that we need high-quality data types. In some cases this is possible while supporting simple translations from SNMP MIBs, but in other cases it will not. In the cases where optimizing for the translation results in sub-optimal data types definitions for use in NETCONF, we need go with the high-quality types. (And no, I don't have a concrete definition of 'high-quality'). In this case, it may be possible to align on a single definition for these items. I believe that Bob's is missing a namespace declaration, so that need to be addressed. I think then the only definition of potential interest from that set was IpAddress, but as defined it I don't think it supports ipV6, or if it does, it doesn't do it with ":" separators. I think the inet:host schema in the monitoring draft has a more complete solution for IP addresses. If we decide we want to merge this work, then it needs to be published in a specification that isn't SNMP specific. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, July 23, 2008 8:45 AM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > There is a set of potential XML-based management applications -- and a > user community that needs them -- that requires maximum compatibility > and interoperability with legacy/existing SNMP management applications > and managed resources. In that context, these applications -- and > their developers and their users -- do not need "anything better" or > anything "extra" ... they need as close to the original as possible ... > and sooner rather than later. Let them speak up here... > Hence, the "XSDMI" effort -- which continues to strive to avoid > gratuitous incompatibilities with the rest of the IETF O&M world, but > does claim to have valid requirements for the stated purpose. I have not seen anybody doing "gratuitous incompatibilities" lately. As you know, there are tools like libsmi that do already SMIv2 to XSD and SMIv2 to YANG conversions and there are already tools to do YANG to XSD conversions. Being involved with some of the tools, I like to see the result produced to be identical since I believe this gives us a long term benefit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 23 10:20:23 2008 Return-Path: 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 204003A682A; Wed, 23 Jul 2008 10:20:23 -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 C35F03A682A for ; Wed, 23 Jul 2008 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] 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 YDsx6SSKx8KX for ; Wed, 23 Jul 2008 10:20:22 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D0DDC3A6407 for ; Wed, 23 Jul 2008 10:20:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="128386588" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Jul 2008 13:21:04 -0400 X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="234422875" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jul 2008 13:21:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 19:21:01 +0200 Message-ID: In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIA== References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> From: "Romascanu, Dan (Dan)" To: "Natale, Bob" , "Sharon Chisholm" , Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > 2. The SMIv2 (RFC2578) definition of IpAddress is: > IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > FWIW - this is not any longer sufficient. See RFC4001 Several standards-track MIB modules use the IpAddress SMIv2 base type. This limits the applicability of these MIB modules to IP Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become problematic with the introduction of IP Version 6 (IPv6) addresses [RFC3513]. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 10:20:23 2008 Return-Path: X-Original-To: netconf-archive@lists.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 204003A682A; Wed, 23 Jul 2008 10:20:23 -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 C35F03A682A for ; Wed, 23 Jul 2008 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] 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 YDsx6SSKx8KX for ; Wed, 23 Jul 2008 10:20:22 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D0DDC3A6407 for ; Wed, 23 Jul 2008 10:20:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="128386588" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Jul 2008 13:21:04 -0400 X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="234422875" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jul 2008 13:21:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 19:21:01 +0200 Message-ID: In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIA== References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> From: "Romascanu, Dan (Dan)" To: "Natale, Bob" , "Sharon Chisholm" , Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > 2. The SMIv2 (RFC2578) definition of IpAddress is: > IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > FWIW - this is not any longer sufficient. See RFC4001 Several standards-track MIB modules use the IpAddress SMIv2 base type. This limits the applicability of these MIB modules to IP Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become problematic with the introduction of IP Version 6 (IPv6) addresses [RFC3513]. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 13:11:31 2008 Return-Path: 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 8461B3A6AF0; Wed, 23 Jul 2008 13:11:31 -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 003AB3A6AFE for ; Wed, 23 Jul 2008 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] 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 ruVpeJopm+dS for ; Wed, 23 Jul 2008 13:11:28 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A88B33A6887 for ; Wed, 23 Jul 2008 13:11:28 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id tUUB1Z0040EPchoA1YCC2r; Wed, 23 Jul 2008 20:12:12 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id tYC91Z00C4HwxpC8MYCAfR; Wed, 23 Jul 2008 20:12:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=lHTQJM2IAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=7yNikN9haoHx0C9Yt-gA:9 a=_v11JNH8nAZzm9FB-SQA:9 a=vH1ynVAiQEado-ON39QA:7 a=HlHnco_TaNtf7aijXuw87H8btDAA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=ZPn7O4N2MpQA:10 a=HMmPKh5NLbsA:10 From: "David B Harrington" To: "'Natale, Bob'" , "'Sharon Chisholm'" , References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Date: Wed, 23 Jul 2008 16:12:09 -0400 Message-ID: <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAABK7CYA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Gee, I think we should shoot for low-quality data types. ;-) Seriously, what defines a "better" datatype? I will use the BridgeId definition in YANG-LIB as an example. BridgeId in RFC4188 is defined to match the binary representation pulled from 802.1D spanning tree messages. IETF and IEEE agreed on this format. bridgeid in YANG-LIB is defined to use a textual formatted string with a colon separator instead. (and it uses a "reference" of RFC4188, which seems odd) Which is better? Which is more "high-quality"? Which is better for directly comparing to the binary values passed in the spanning tree BPDU? Which one has chosen to diverge so now we have two different XSD datatypes? XSDMI is designed explicitly to be faithful to the original SMIv2 definitions. XSDMI is designed to explicitly avoid "improving" the SMIv2 datatypes. XSDMI and YANG-LIB have different purposes, and different formats are "better" for different purposes. It is perfectly legal to have different XML schemas to represent the same thing for different (or even the same) purpose. SMIv2 datatypes are IETF standards, and XSDMI is trying to remain true to the standard datatypes developed by IETF community consensus. If you want to change those standards because you think you can do better, then go open a WG to change all the existing MIBs to match your "better" definitions. Oh, and for BridgeId don't forget to open projects in IEEE to change their MIB modules, and maybe their BPDU formats, as well. XSDMI wants to use the existing SMIv2 definitions as faithfully as possible because we think those are "high-quality" definitons already agreed to by the IETF community, and using the same definition/format is likely to enhance interoperability. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > Sent: Wednesday, July 23, 2008 1:12 PM > To: Sharon Chisholm; j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi Sharon, > > Thanks for the observations: > > 1. I will add the namespace definition in an -03 update imminently -- > oversight in -02. > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > That is all -- with the associated value restrictions -- XSDMI intends > to represent in the base SMI datatypes set. > > I don't have a view on the need for high-quality data types (sure > sounds like a good thing though) -- I'm just concerned in this context > with XSD to validate the direct translation of SMI-compliant SNMP data > into XML. > > Cheers, > BobN > > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, July 23, 2008 9:44 AM > To: j.schoenwaelder@jacobs-university.de; Natale, Bob > Cc: netconf@ietf.org > Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi > > My view on this topic is that we need high-quality data types. In some > cases this is possible while supporting simple translations from SNMP > MIBs, but in other cases it will not. In the cases where > optimizing for > the translation results in sub-optimal data types definitions for use > in > NETCONF, we need go with the high-quality types. (And no, I don't have > a > concrete definition of 'high-quality'). > > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, > so > that need to be addressed. I think then the only definition of > potential > interest from that set was IpAddress, but as defined it I don't think > it > supports ipV6, or if it does, it doesn't do it with ":" separators. I > think the inet:host schema in the monitoring draft has a more complete > solution for IP addresses. If we decide we want to merge this work, > then > it needs to be published in a specification that isn't SNMP specific. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, July 23, 2008 8:45 AM > To: Natale, Bob > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > > > There is a set of potential XML-based management applications -- and > a > > > user community that needs them -- that requires maximum > compatibility > > > and interoperability with legacy/existing SNMP management > applications > > > and managed resources. In that context, these applications -- and > > their developers and their users -- do not need "anything > better" or > > anything "extra" ... they need as close to the original as possible > ... > > and sooner rather than later. > > Let them speak up here... > > > Hence, the "XSDMI" effort -- which continues to strive to avoid > > gratuitous incompatibilities with the rest of the IETF O&M > world, but > > > does claim to have valid requirements for the stated purpose. > > I have not seen anybody doing "gratuitous incompatibilities" lately. > > As you know, there are tools like libsmi that do already SMIv2 to XSD > and SMIv2 to YANG conversions and there are already tools to > do YANG to > XSD conversions. Being involved with some of the tools, I like to see > the result produced to be identical since I believe this gives us a > long > term benefit. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 13:11:31 2008 Return-Path: X-Original-To: netconf-archive@lists.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 8461B3A6AF0; Wed, 23 Jul 2008 13:11:31 -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 003AB3A6AFE for ; Wed, 23 Jul 2008 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] 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 ruVpeJopm+dS for ; Wed, 23 Jul 2008 13:11:28 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A88B33A6887 for ; Wed, 23 Jul 2008 13:11:28 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id tUUB1Z0040EPchoA1YCC2r; Wed, 23 Jul 2008 20:12:12 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id tYC91Z00C4HwxpC8MYCAfR; Wed, 23 Jul 2008 20:12:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=lHTQJM2IAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=7yNikN9haoHx0C9Yt-gA:9 a=_v11JNH8nAZzm9FB-SQA:9 a=vH1ynVAiQEado-ON39QA:7 a=HlHnco_TaNtf7aijXuw87H8btDAA:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=ZPn7O4N2MpQA:10 a=HMmPKh5NLbsA:10 From: "David B Harrington" To: "'Natale, Bob'" , "'Sharon Chisholm'" , References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Date: Wed, 23 Jul 2008 16:12:09 -0400 Message-ID: <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAABK7CYA== Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Gee, I think we should shoot for low-quality data types. ;-) Seriously, what defines a "better" datatype? I will use the BridgeId definition in YANG-LIB as an example. BridgeId in RFC4188 is defined to match the binary representation pulled from 802.1D spanning tree messages. IETF and IEEE agreed on this format. bridgeid in YANG-LIB is defined to use a textual formatted string with a colon separator instead. (and it uses a "reference" of RFC4188, which seems odd) Which is better? Which is more "high-quality"? Which is better for directly comparing to the binary values passed in the spanning tree BPDU? Which one has chosen to diverge so now we have two different XSD datatypes? XSDMI is designed explicitly to be faithful to the original SMIv2 definitions. XSDMI is designed to explicitly avoid "improving" the SMIv2 datatypes. XSDMI and YANG-LIB have different purposes, and different formats are "better" for different purposes. It is perfectly legal to have different XML schemas to represent the same thing for different (or even the same) purpose. SMIv2 datatypes are IETF standards, and XSDMI is trying to remain true to the standard datatypes developed by IETF community consensus. If you want to change those standards because you think you can do better, then go open a WG to change all the existing MIBs to match your "better" definitions. Oh, and for BridgeId don't forget to open projects in IEEE to change their MIB modules, and maybe their BPDU formats, as well. XSDMI wants to use the existing SMIv2 definitions as faithfully as possible because we think those are "high-quality" definitons already agreed to by the IETF community, and using the same definition/format is likely to enhance interoperability. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > Sent: Wednesday, July 23, 2008 1:12 PM > To: Sharon Chisholm; j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi Sharon, > > Thanks for the observations: > > 1. I will add the namespace definition in an -03 update imminently -- > oversight in -02. > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > That is all -- with the associated value restrictions -- XSDMI intends > to represent in the base SMI datatypes set. > > I don't have a view on the need for high-quality data types (sure > sounds like a good thing though) -- I'm just concerned in this context > with XSD to validate the direct translation of SMI-compliant SNMP data > into XML. > > Cheers, > BobN > > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, July 23, 2008 9:44 AM > To: j.schoenwaelder@jacobs-university.de; Natale, Bob > Cc: netconf@ietf.org > Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi > > My view on this topic is that we need high-quality data types. In some > cases this is possible while supporting simple translations from SNMP > MIBs, but in other cases it will not. In the cases where > optimizing for > the translation results in sub-optimal data types definitions for use > in > NETCONF, we need go with the high-quality types. (And no, I don't have > a > concrete definition of 'high-quality'). > > In this case, it may be possible to align on a single definition for > these items. I believe that Bob's is missing a namespace declaration, > so > that need to be addressed. I think then the only definition of > potential > interest from that set was IpAddress, but as defined it I don't think > it > supports ipV6, or if it does, it doesn't do it with ":" separators. I > think the inet:host schema in the monitoring draft has a more complete > solution for IP addresses. If we decide we want to merge this work, > then > it needs to be published in a specification that isn't SNMP specific. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, July 23, 2008 8:45 AM > To: Natale, Bob > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 07:42:39AM -0400, Natale, Bob wrote: > > > There is a set of potential XML-based management applications -- and > a > > > user community that needs them -- that requires maximum > compatibility > > > and interoperability with legacy/existing SNMP management > applications > > > and managed resources. In that context, these applications -- and > > their developers and their users -- do not need "anything > better" or > > anything "extra" ... they need as close to the original as possible > ... > > and sooner rather than later. > > Let them speak up here... > > > Hence, the "XSDMI" effort -- which continues to strive to avoid > > gratuitous incompatibilities with the rest of the IETF O&M > world, but > > > does claim to have valid requirements for the stated purpose. > > I have not seen anybody doing "gratuitous incompatibilities" lately. > > As you know, there are tools like libsmi that do already SMIv2 to XSD > and SMIv2 to YANG conversions and there are already tools to > do YANG to > XSD conversions. Being involved with some of the tools, I like to see > the result produced to be identical since I believe this gives us a > long > term benefit. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > 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 mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 23 13:33:16 2008 Return-Path: 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 0BC393A68AA; Wed, 23 Jul 2008 13:33:16 -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 002513A68AA for ; Wed, 23 Jul 2008 13:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 1IriVANTunff for ; Wed, 23 Jul 2008 13:33:14 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 2775C3A6887 for ; Wed, 23 Jul 2008 13:33:14 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id tWTQ1Z0471GXsucA1YZxRh; Wed, 23 Jul 2008 20:33:57 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id tYZv1Z00F4HwxpC8TYZwm8; Wed, 23 Jul 2008 20:33:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=48vgC7mUAAAA:8 a=9d12lo-U8R5U46w3ufYA:9 a=mL0_03UuJklrauEynSYA:9 a=7hPUFl7gGWRcGXtzGhgcBFmJTY4A:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Natale, Bob'" , "'Sharon Chisholm'" , References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com><4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Date: Wed, 23 Jul 2008 16:33:56 -0400 Message-ID: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIAAGCDjQ Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, That is probably why SMIv2 includes the comment line: -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) There are still MIB modules that have IpAddress type objects in them, and some applications (such as manager) night want to be able to (faithfully) represent that value in an XML format. XSDMI does not recommend using this type; it merely provides a translation of an existing IETF standard datatype. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Wednesday, July 23, 2008 1:21 PM > To: Natale, Bob; Sharon Chisholm; j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > > IpAddress ::= > > [APPLICATION 0] > > IMPLICIT OCTET STRING (SIZE (4)) > > > > > > FWIW - this is not any longer sufficient. > > See RFC4001 > > Several standards-track MIB modules use the IpAddress SMIv2 base > type. This limits the applicability of these MIB modules to IP > Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain > 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become > problematic with the introduction of IP Version 6 (IPv6) addresses > [RFC3513]. > > Dan > _______________________________________________ > 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 From netconf-bounces@ietf.org Wed Jul 23 13:33:16 2008 Return-Path: X-Original-To: netconf-archive@lists.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 0BC393A68AA; Wed, 23 Jul 2008 13:33:16 -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 002513A68AA for ; Wed, 23 Jul 2008 13:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 1IriVANTunff for ; Wed, 23 Jul 2008 13:33:14 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 2775C3A6887 for ; Wed, 23 Jul 2008 13:33:14 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id tWTQ1Z0471GXsucA1YZxRh; Wed, 23 Jul 2008 20:33:57 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id tYZv1Z00F4HwxpC8TYZwm8; Wed, 23 Jul 2008 20:33:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=48vgC7mUAAAA:8 a=9d12lo-U8R5U46w3ufYA:9 a=mL0_03UuJklrauEynSYA:9 a=7hPUFl7gGWRcGXtzGhgcBFmJTY4A:4 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Natale, Bob'" , "'Sharon Chisholm'" , References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com><4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> Date: Wed, 23 Jul 2008 16:33:56 -0400 Message-ID: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIAAGCDjQ Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, That is probably why SMIv2 includes the comment line: -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) There are still MIB modules that have IpAddress type objects in them, and some applications (such as manager) night want to be able to (faithfully) represent that value in an XML format. XSDMI does not recommend using this type; it merely provides a translation of an existing IETF standard datatype. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Wednesday, July 23, 2008 1:21 PM > To: Natale, Bob; Sharon Chisholm; j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > > IpAddress ::= > > [APPLICATION 0] > > IMPLICIT OCTET STRING (SIZE (4)) > > > > > > FWIW - this is not any longer sufficient. > > See RFC4001 > > Several standards-track MIB modules use the IpAddress SMIv2 base > type. This limits the applicability of these MIB modules to IP > Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain > 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become > problematic with the introduction of IP Version 6 (IPv6) addresses > [RFC3513]. > > Dan > _______________________________________________ > 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 From netconf-bounces@ietf.org Wed Jul 23 13:35:50 2008 Return-Path: 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 567373A6AF6; Wed, 23 Jul 2008 13:35:50 -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 3BF423A6ADE for ; Wed, 23 Jul 2008 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] 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 8-Irpckdyxw9 for ; Wed, 23 Jul 2008 13:35:48 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D6EDF3A6AF6 for ; Wed, 23 Jul 2008 13:35:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="128412767" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Jul 2008 16:36:29 -0400 X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="234524681" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jul 2008 16:36:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 22:36:27 +0200 Message-ID: In-Reply-To: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIAAGCDjQAADFQ1A= References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com><4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Natale, Bob" , "Sharon Chisholm" , Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org So I assume that there are or will be in XSDMI corresponding translations of the RFC4001 TCs, right? Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, July 23, 2008 11:34 PM > To: Romascanu, Dan (Dan); 'Natale, Bob'; 'Sharon Chisholm'; > j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi, > > That is probably why SMIv2 includes the comment line: > > -- (this is a tagged type for historical reasons) IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > There are still MIB modules that have IpAddress type objects > in them, and some applications (such as manager) night want > to be able to > (faithfully) represent that value in an XML format. > XSDMI does not recommend using this type; it merely provides > a translation of an existing IETF standard datatype. > > dbh > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Wednesday, July 23, 2008 1:21 PM > > To: Natale, Bob; Sharon Chisholm; > j.schoenwaelder@jacobs-university.de > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org > > > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > > > > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > > > IpAddress ::= > > > [APPLICATION 0] > > > IMPLICIT OCTET STRING (SIZE (4)) > > > > > > > > > > FWIW - this is not any longer sufficient. > > > > See RFC4001 > > > > Several standards-track MIB modules use the IpAddress SMIv2 base > > type. This limits the applicability of these MIB modules to IP > > Version 4 (IPv4), as the IpAddress SMIv2 base type can only > contain > > 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become > > problematic with the introduction of IP Version 6 (IPv6) > addresses > > [RFC3513]. > > > > Dan > > _______________________________________________ > > 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 From netconf-bounces@ietf.org Wed Jul 23 13:35:50 2008 Return-Path: X-Original-To: netconf-archive@lists.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 567373A6AF6; Wed, 23 Jul 2008 13:35:50 -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 3BF423A6ADE for ; Wed, 23 Jul 2008 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] 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 8-Irpckdyxw9 for ; Wed, 23 Jul 2008 13:35:48 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id D6EDF3A6AF6 for ; Wed, 23 Jul 2008 13:35:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="128412767" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 23 Jul 2008 16:36:29 -0400 X-IronPort-AV: E=Sophos;i="4.31,239,1215403200"; d="scan'208";a="234524681" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 23 Jul 2008 16:36:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 22:36:27 +0200 Message-ID: In-Reply-To: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjswfYaYD+1fAl+T1Ocn/wdu0/aIwABtHhAAAdFhaAAAKNzIAAGCDjQAADFQ1A= References: <4885CB51.1000703@ericsson.com><713043CE8B8E1348AF3C546DBE02C1B41594502D@zcarhxm2.corp.nortel.com><48864924.8040307@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4A71@IMCSRV2.MITRE.ORG><4886EE38.3090201@ericsson.com><4915F014FDD99049A9C3A8C1B832004F02DB4AD2@IMCSRV2.MITRE.ORG><20080723124502.GA3425@elstar.local><713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com><4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Natale, Bob" , "Sharon Chisholm" , Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org So I assume that there are or will be in XSDMI corresponding translations of the RFC4001 TCs, right? Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, July 23, 2008 11:34 PM > To: Romascanu, Dan (Dan); 'Natale, Bob'; 'Sharon Chisholm'; > j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: RE: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hi, > > That is probably why SMIv2 includes the comment line: > > -- (this is a tagged type for historical reasons) IpAddress ::= > [APPLICATION 0] > IMPLICIT OCTET STRING (SIZE (4)) > > There are still MIB modules that have IpAddress type objects > in them, and some applications (such as manager) night want > to be able to > (faithfully) represent that value in an XML format. > XSDMI does not recommend using this type; it merely provides > a translation of an existing IETF standard datatype. > > dbh > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Wednesday, July 23, 2008 1:21 PM > > To: Natale, Bob; Sharon Chisholm; > j.schoenwaelder@jacobs-university.de > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] Review of > draft-ietf-netconf-monitoring-02.txt > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org > > > [mailto:netconf-bounces@ietf.org] On Behalf Of Natale, Bob > > > > > 2. The SMIv2 (RFC2578) definition of IpAddress is: > > > IpAddress ::= > > > [APPLICATION 0] > > > IMPLICIT OCTET STRING (SIZE (4)) > > > > > > > > > > FWIW - this is not any longer sufficient. > > > > See RFC4001 > > > > Several standards-track MIB modules use the IpAddress SMIv2 base > > type. This limits the applicability of these MIB modules to IP > > Version 4 (IPv4), as the IpAddress SMIv2 base type can only > contain > > 4-byte IPv4 addresses. The IpAddress SMIv2 base type has become > > problematic with the introduction of IP Version 6 (IPv6) > addresses > > [RFC3513]. > > > > Dan > > _______________________________________________ > > 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 From netconf-bounces@ietf.org Thu Jul 24 00:44:34 2008 Return-Path: X-Original-To: netconf-archive@lists.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 2B7E73A691C; Thu, 24 Jul 2008 00:44:34 -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 314443A6959 for ; Thu, 24 Jul 2008 00:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 xwl9V8sMG3+z for ; Thu, 24 Jul 2008 00:44:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D81AC3A67A4 for ; Thu, 24 Jul 2008 00:44:31 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E807EC004C; Thu, 24 Jul 2008 09:45:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vPIOF3lqggzi; Thu, 24 Jul 2008 09:45:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE623C001D; Thu, 24 Jul 2008 09:45:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D299673B13; Thu, 24 Jul 2008 09:45:09 +0200 (CEST) Date: Thu, 24 Jul 2008 09:45:09 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724074509.GA5161@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > So I assume that there are or will be in XSDMI corresponding > translations of the RFC4001 TCs, right? There are tools out there translate everything you can define in SMIv2 to XSD by means of relatively simple translation rules. There is IMHO no point in hand translating selected TCs. Instead, you have to specify the translation rules and everything falls out from that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 35From netconf-bounces@ietf.org Thu Jul 24 00:44:34 2008 Return-Path: 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 2B7E73A691C; Thu, 24 Jul 2008 00:44:34 -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 314443A6959 for ; Thu, 24 Jul 2008 00:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 xwl9V8sMG3+z for ; Thu, 24 Jul 2008 00:44:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D81AC3A67A4 for ; Thu, 24 Jul 2008 00:44:31 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E807EC004C; Thu, 24 Jul 2008 09:45:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vPIOF3lqggzi; Thu, 24 Jul 2008 09:45:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE623C001D; Thu, 24 Jul 2008 09:45:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D299673B13; Thu, 24 Jul 2008 09:45:09 +0200 (CEST) Date: Thu, 24 Jul 2008 09:45:09 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724074509.GA5161@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > So I assume that there are or will be in XSDMI corresponding > translations of the RFC4001 TCs, right? There are tools out there translate everything you can define in SMIv2 to XSD by means of relatively simple translation rules. There is IMHO no point in hand translating selected TCs. Instead, you have to specify the translation rules and everything falls out from that. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 87 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 00:53:16 2008 Return-Path: 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 589AE3A6972; Thu, 24 Jul 2008 00:53:16 -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 7C4DB3A6972 for ; Thu, 24 Jul 2008 00:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 R4Ic-E1oU402 for ; Thu, 24 Jul 2008 00:53:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4C6DE3A6902 for ; Thu, 24 Jul 2008 00:53:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="115815168" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jul 2008 03:53:56 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241629766" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 03:53:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 09:53:45 +0200 Message-ID: In-Reply-To: <20080724074509.GA5161@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtYTlNkERdkQ5JQiiY0xWyQbt8DAAAGgQw References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 10:45 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > > > So I assume that there are or will be in XSDMI corresponding > > translations of the RFC4001 TCs, right? > > There are tools out there translate everything you can define > in SMIv2 to XSD by means of relatively simple translation > rules. There is IMHO no point in hand translating selected > TCs. Instead, you have to specify the translation rules and > everything falls out from that. > > /js > So, in your opinion, the specification of the translation rules shFrom netconf-bounces@ietf.org Thu Jul 24 00:53:16 2008 Return-Path: X-Original-To: netconf-archive@lists.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 589AE3A6972; Thu, 24 Jul 2008 00:53:16 -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 7C4DB3A6972 for ; Thu, 24 Jul 2008 00:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 R4Ic-E1oU402 for ; Thu, 24 Jul 2008 00:53:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4C6DE3A6902 for ; Thu, 24 Jul 2008 00:53:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="115815168" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jul 2008 03:53:56 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241629766" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 03:53:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 09:53:45 +0200 Message-ID: In-Reply-To: <20080724074509.GA5161@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtYTlNkERdkQ5JQiiY0xWyQbt8DAAAGgQw References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 10:45 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > > > So I assume that there are or will be in XSDMI corresponding > > translations of the RFC4001 TCs, right? > > There are tools out there translate everything you can define > in SMIv2 to XSD by means of relatively simple translation > rules. There is IMHO no point in hand translating selected > TCs. Instead, you have to specify the translation rules and > everything falls out from that. > > /js > So, in your opinion, the specification of the translation rules should be the sole (principal?) scope of standardization in this area? Or is there a need to optimize the output to get that 'better quality' level for some of the commonly used structures? Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ould be the sole (principal?) scope of standardization in this area? Or is there a need to optimize the output to get that 'better quality' level for some of the commonly used structures? Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 00:55:13 2008 Return-Path: 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 B8EBA3A69BB; Thu, 24 Jul 2008 00:55:13 -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 EEB6A3A69BB for ; Thu, 24 Jul 2008 00:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 qRyv0E4pHLZu for ; Thu, 24 Jul 2008 00:55:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CAD193A69BA for ; Thu, 24 Jul 2008 00:55:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1241C0027; Thu, 24 Jul 2008 09:55:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id an1X78NEDnrR; Thu, 24 Jul 2008 09:55:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 875E6C0011; Thu, 24 Jul 2008 09:55:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36567673B4E; Thu, 24 Jul 2008 09:55:49 +0200 (CEST) Date: Thu, 24 Jul 2008 09:55:49 +0200 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20080724075549.GB5161@elstar.local> Mail-Followup-To: David B Harrington , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 04:12:09PM -0400, David B Harrington wrote: > I will use the BridgeId definition in YANG-LIB as an example. There is not YANG-LIB - but I know what you mean. ;-) > BridgeId in RFC4188 is defined to match the binary representation > pulled from 802.1D spanning tree messages. IETF and IEEE agreed on > this format. > bridgeid in YANG-LIB is defined to use a textual formatted string with > a colon separator instead. (and it uses a "reference" of RFC4188, > which seems odd) So what do you think is the appropriate "faithful to SMIv2" representation of BridgeId in XML? > Which is better? > Which is more "high-quality"? > Which is better for directly comparing to the binary values passed in > the spanning tree BPDU? > Which one has chosen to diverge so now we have two different XSD > datatypes? Can you explain to me why represents an IP address in dotted quad notation while it is on the wire (in SNMP and IP) just a four octet field? Can you explain to me why the same document represents OIDs in dotted number notation while they are BER encoded 7bit binary number sequences in SNMP? Can you answer the above questions for each of these examples? > XSDMI is designed explicitly to be faithful to the original SMIv2 > definitions. XSDMI is designed to explicitly avoid "improving" the > SMIv2 datatypes. > > XSDMI and YANG-LIB have different purposes, and different formats are > "better" for different purposes. It is perfectly legal to have > different XML schemas to represent the same thing for different (or > even the same) purpose. > > SMIv2 datatypes are IETF standards, and XSDMI is trying to remain true > to the standard datatypes developed by IETF community consensus. If > you want to change those standards because you think you can do > better, then go open a WG to change all the existing MIBs to match > your "better" definitions. Oh, and for BridgeId don't forget to open > projects in IEEE to change their MIB modules, and maybe their BPDU > formats, as well. In the light of the current XSDMI definition, I think you are slighly exaggerating. Or are you going to ask the IETF to redo IPv4 because of the new XSDMI definition of an IPv4 address? > XSDMI wants to use the existing SMIv2 definitions as faithfully as > possible because we think those are "high-quality" definitons already > agreed to by the IETF community, and using the same definition/format > is likely to enhance interoperability. I guess we need a definition of "faithfully" now in addition to a definition of "better". I suggest to do a bar bof next week to clarify all these terms. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 00:55:13 2008 Return-Path: X-Original-To: netconf-archive@lists.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 B8EBA3A69BB; Thu, 24 Jul 2008 00:55:13 -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 EEB6A3A69BB for ; Thu, 24 Jul 2008 00:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 qRyv0E4pHLZu for ; Thu, 24 Jul 2008 00:55:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CAD193A69BA for ; Thu, 24 Jul 2008 00:55:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1241C0027; Thu, 24 Jul 2008 09:55:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id an1X78NEDnrR; Thu, 24 Jul 2008 09:55:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 875E6C0011; Thu, 24 Jul 2008 09:55:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36567673B4E; Thu, 24 Jul 2008 09:55:49 +0200 (CEST) Date: Thu, 24 Jul 2008 09:55:49 +0200 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20080724075549.GB5161@elstar.local> Mail-Followup-To: David B Harrington , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG> <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <002b01c8ed00$6467db50$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 23, 2008 at 04:12:09PM -0400, David B Harrington wrote: > I will use the BridgeId definition in YANG-LIB as an example. There is not YANG-LIB - but I know what you mean. ;-) > BridgeId in RFC4188 is defined to match the binary representation > pulled from 802.1D spanning tree messages. IETF and IEEE agreed on > this format. > bridgeid in YANG-LIB is defined to use a textual formatted string with > a colon separator instead. (and it uses a "reference" of RFC4188, > which seems odd) So what do you think is the appropriate "faithful to SMIv2" representation of BridgeId in XML? > Which is better? > Which is more "high-quality"? > Which is better for directly comparing to the binary values passed in > the spanning tree BPDU? > Which one has chosen to diverge so now we have two different XSD > datatypes? Can you explain to me why represents an IP address in dotted quad notation while it is on the wire (in SNMP and IP) just a four octet field? Can you explain to me why the same document represents OIDs in dotted number notation while they are BER encoded 7bit binary number sequences in SNMP? Can you answer the above questions for each of these examples? > XSDMI is designed explicitly to be faithful to the original SMIv2 > definitions. XSDMI is designed to explicitly avoid "improving" the > SMIv2 datatypes. > > XSDMI and YANG-LIB have different purposes, and different formats are > "better" for different purposes. It is perfectly legal to have > different XML schemas to represent the same thing for different (or > even the same) purpose. > > SMIv2 datatypes are IETF standards, and XSDMI is trying to remain true > to the standard datatypes developed by IETF community consensus. If > you want to change those standards because you think you can do > better, then go open a WG to change all the existing MIBs to match > your "better" definitions. Oh, and for BridgeId don't forget to open > projects in IEEE to change their MIB modules, and maybe their BPDU > formats, as well. In the light of the current XSDMI definition, I think you are slighly exaggerating. Or are you going to ask the IETF to redo IPv4 because of the new XSDMI definition of an IPv4 address? > XSDMI wants to use the existing SMIv2 definitions as faithfully as > possible because we think those are "high-quality" definitons already > agreed to by the IETF community, and using the same definition/format > is likely to enhance interoperability. I guess we need a definition of "faithfully" now in addition to a definition of "better". I suggest to do a bar bof next week to clarify all these terms. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 01:39:23 2008 Return-Path: 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 115163A697C; Thu, 24 Jul 2008 01:39:23 -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 7F0CA3A69B8 for ; Thu, 24 Jul 2008 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 u38wQE1vuWhm for ; Thu, 24 Jul 2008 01:39:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 311793A6967 for ; Thu, 24 Jul 2008 01:39:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 535B4C004C; Thu, 24 Jul 2008 10:40:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m2fwgbyMo+4G; Thu, 24 Jul 2008 10:39:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F2BC001D; Thu, 24 Jul 2008 10:39:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F42B673BD3; Thu, 24 Jul 2008 10:39:59 +0200 (CEST) Date: Thu, 24 Jul 2008 10:39:59 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724083958.GC5161@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > So, in your opinion, the specification of the translation rules should > be the sole (principal?) scope of standardization in this area? Or is > there a need to optimize the output to get that 'better quality' level > for some of the commonly used structures? There are two work items we have to distinguish: a] The first work item is reuse of existing SMIv2 definitions in XML based protocols and for this we need translation rules. Whether the rules contain very specific rules to deal with some specific but frequently occuring constructs is subject to the group defining the rules. At the end, however, everything has to be automatic since nobody is going to hand translate stuff that is out there. b] The second work item are data types for new definitions. In some cases, translation rules will not produce reasonable results (a good example is the InetAddress family of TCs that try to work around the lack of proper unions in the SMIv2). While any new definitions should align to existing definitions as much as possible, there will be cases where this requires discussion. For me, the BridgeID is a good example of this kind of discussion and there is in my view no way to avoid these discussions for cases where the binary representation implied by the SMIv2 does not match the more textual XSD approach or where the SMIv2 representation is specific to SNMP and SMIv2 limitations which do not exist in other XML based protocols such as NETCONF. My understanding was that XSDMI is addressing a] while NETMOD will work on b] to produce reusable constructs for new configuration data models. Excursion to the real world: I am familiar with a particular implementation that has translation rules to directly translate SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can do already today: 1) FOO-MIB -> FOO-MIB.xsd 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd And the result is not the same. Assuming that NETCONF will be used to provide access to SMIv2 instrumentation, I believe we are in trouble. Back from the real world to the IETF: There is a work item in the OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG (the YANG->XSD mapping). So from your perspective, you can say there is no problem as of now. ;-) In practice, there is already running code for all of this and if we do not find a way to make the translation rules consistent in time (whatever that means in the IETF ;-), I believe we will see that people use differnet translation rules and we are going to pay the bill later on. There are different solutions possible to deal with this issue. Some solutions I quickly can come up with (but this is not meant to be a complete list): a) Translation of SMIv2 to YANG is simply forbitten, only the direct translation to XSD is allowed. b) Both translations are developed at the same time and we ensure that things are coordinated and that at the end that the outcome of the two translation paths is consistent. c) Both translation roads are engineered in parallel and who completes first wins and the other one has to adapt to the winner, regardless how painful this will be. d) Settle on a single translation approach but make sure that everyone interested in the other approach is made aware to follow it closely to ensure that problems are avoided (this is essentially b) without managed coordination). e) Declare that this problem is not worth solving since XML namespaces will take care of the differences and application writers can deal with it. f) Postpone the problem. All I am suggesting is to discuss this issue openly and fairly on technical grounds with the goal to avoid incompatible XSD translations of SMIv2 modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 01:39:23 2008 Return-Path: X-Original-To: netconf-archive@lists.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 115163A697C; Thu, 24 Jul 2008 01:39:23 -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 7F0CA3A69B8 for ; Thu, 24 Jul 2008 01:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 u38wQE1vuWhm for ; Thu, 24 Jul 2008 01:39:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 311793A6967 for ; Thu, 24 Jul 2008 01:39:21 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 535B4C004C; Thu, 24 Jul 2008 10:40:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m2fwgbyMo+4G; Thu, 24 Jul 2008 10:39:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F2BC001D; Thu, 24 Jul 2008 10:39:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F42B673BD3; Thu, 24 Jul 2008 10:39:59 +0200 (CEST) Date: Thu, 24 Jul 2008 10:39:59 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724083958.GC5161@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > So, in your opinion, the specification of the translation rules should > be the sole (principal?) scope of standardization in this area? Or is > there a need to optimize the output to get that 'better quality' level > for some of the commonly used structures? There are two work items we have to distinguish: a] The first work item is reuse of existing SMIv2 definitions in XML based protocols and for this we need translation rules. Whether the rules contain very specific rules to deal with some specific but frequently occuring constructs is subject to the group defining the rules. At the end, however, everything has to be automatic since nobody is going to hand translate stuff that is out there. b] The second work item are data types for new definitions. In some cases, translation rules will not produce reasonable results (a good example is the InetAddress family of TCs that try to work around the lack of proper unions in the SMIv2). While any new definitions should align to existing definitions as much as possible, there will be cases where this requires discussion. For me, the BridgeID is a good example of this kind of discussion and there is in my view no way to avoid these discussions for cases where the binary representation implied by the SMIv2 does not match the more textual XSD approach or where the SMIv2 representation is specific to SNMP and SMIv2 limitations which do not exist in other XML based protocols such as NETCONF. My understanding was that XSDMI is addressing a] while NETMOD will work on b] to produce reusable constructs for new configuration data models. Excursion to the real world: I am familiar with a particular implementation that has translation rules to directly translate SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can do already today: 1) FOO-MIB -> FOO-MIB.xsd 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd And the result is not the same. Assuming that NETCONF will be used to provide access to SMIv2 instrumentation, I believe we are in trouble. Back from the real world to the IETF: There is a work item in the OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG (the YANG->XSD mapping). So from your perspective, you can say there is no problem as of now. ;-) In practice, there is already running code for all of this and if we do not find a way to make the translation rules consistent in time (whatever that means in the IETF ;-), I believe we will see that people use differnet translation rules and we are going to pay the bill later on. There are different solutions possible to deal with this issue. Some solutions I quickly can come up with (but this is not meant to be a complete list): a) Translation of SMIv2 to YANG is simply forbitten, only the direct translation to XSD is allowed. b) Both translations are developed at the same time and we ensure that things are coordinated and that at the end that the outcome of the two translation paths is consistent. c) Both translation roads are engineered in parallel and who completes first wins and the other one has to adapt to the winner, regardless how painful this will be. d) Settle on a single translation approach but make sure that everyone interested in the other approach is made aware to follow it closely to ensure that problems are avoided (this is essentially b) without managed coordination). e) Declare that this problem is not worth solving since XML namespaces will take care of the differences and application writers can deal with it. f) Postpone the problem. All I am suggesting is to discuss this issue openly and fairly on technical grounds with the goal to avoid incompatible XSD translations of SMIv2 modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 02:04:17 2008 Return-Path: X-Original-To: netconf-archive@lists.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 399343A68BC; Thu, 24 Jul 2008 02:04:17 -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 3B1DA3A683E for ; Thu, 24 Jul 2008 02:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 hPMg0pd+Q0Pp for ; Thu, 24 Jul 2008 02:04:15 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 932C13A684B for ; Thu, 24 Jul 2008 02:04:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="128465836" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jul 2008 05:04:58 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241656853" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 05:04:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:04:55 +0200 Message-ID: In-Reply-To: <20080724083958.GC5161@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtaOJ/PQ+nax/HRba6hTxhXawrFAAAXnsg References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 11:40 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > > > So, in your opinion, the specification of the translation > rules should > > be the sole (principal?) scope of standardization in this > area? Or is > > there a need to optimize the output to get that 'better > quality' level > > for some of the commonly used structures? > > There are two work items we have to distinguish: > > a] The first work item is reuse of existing SMIv2 definitions in XML > based protocols and for this we need translation rules. Whether the > rules contain very specific rules to deal with some specific but > frequently occuring constructs is subject to the group defining the > rules. At the end, however, everything has to be automatic since > nobody is going to hand translate stuff that is out there. > > b] The second work item are data types for new definitions. In some > cases, translation rules will not produce reasonable results (a > good example is the InetAddress family of TCs that try to work > around the lack of proper unions in the SMIv2). While any new > definitions should align to existing definitions as much as > possible, there will be cases where this requires discussion. For > me, the BridgeID is a good example of this kind of discussion and > there is in my view no way to avoid these discussions for cases > where the binary representation implied by the SMIv2 does not match > the more textual XSD approach or where the SMIv2 representation is > specific to SNMP and SMIv2 limitations which do not exist in other > XML based protocols such as NETCONF. > > My understanding was that XSDMI is addressing a] while NETMOD > will work on b] to produce reusable constructs for new > configuration data models. > > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given > FOO-MIB, I can do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be > used to provide access to SMIv2 instrumentation, I believe we > are in trouble. > > Back from the real world to the IETF: There is a work item in > the OPSAWG to do 1). Approach 2) is covered partially in the > NETMOD WG (the YANG->XSD mapping). So from your perspective, > you can say there is no problem as of now. ;-) > > In practice, there is already running code for all of this > and if we do not find a way to make the translation rules > consistent in time (whatever that means in the IETF ;-), I > believe we will see that people use differnet translation > rules and we are going to pay the bill later on. > > There are different solutions possible to deal with this > issue. Some solutions I quickly can come up with (but this is > not meant to be a complete list): > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > translation to XSD is allowed. > > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. > > c) Both translation roads are engineered in parallel and who completes > first wins and the other one has to adapt to the winner, regardless > how painful this will be. > > d) Settle on a single translation approach but make sure that everyone > interested in the other approach is made aware to follow it closely > to ensure that problems are avoided (this is essentially b) without > managed coordination). > > e) Declare that this problem is not worth solving since XML namespaces > will take care of the differences and application writers can deal > with it. > > f) Postpone the problem. > > All I am suggesting is to discuss this issue openly and > fairly on technical grounds with the goal to avoid > incompatible XSD translations of SMIv2 modules. > > /js > The discussion certainly needs to happen and is happening. My understanding is that the approach taken by the XSDMI is assuming e) and is not necessarily targeting NETCONF (or only NETCONF). This is the approved goal in OPSAWG. Do you feel that the namespace differentiation not enough? After all if the approach that strictly reuses what was defined in SMIv2 will not find an immediate applications, and the NETCONF approach will have clear advantages, no harm will be made to the NETCONF DM path. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 02:04:17 2008 Return-Path: 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 399343A68BC; Thu, 24 Jul 2008 02:04:17 -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 3B1DA3A683E for ; Thu, 24 Jul 2008 02:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] 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 hPMg0pd+Q0Pp for ; Thu, 24 Jul 2008 02:04:15 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 932C13A684B for ; Thu, 24 Jul 2008 02:04:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="128465836" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jul 2008 05:04:58 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241656853" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 05:04:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:04:55 +0200 Message-ID: In-Reply-To: <20080724083958.GC5161@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtaOJ/PQ+nax/HRba6hTxhXawrFAAAXnsg References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 11:40 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > > > So, in your opinion, the specification of the translation > rules should > > be the sole (principal?) scope of standardization in this > area? Or is > > there a need to optimize the output to get that 'better > quality' level > > for some of the commonly used structures? > > There are two work items we have to distinguish: > > a] The first work item is reuse of existing SMIv2 definitions in XML > based protocols and for this we need translation rules. Whether the > rules contain very specific rules to deal with some specific but > frequently occuring constructs is subject to the group defining the > rules. At the end, however, everything has to be automatic since > nobody is going to hand translate stuff that is out there. > > b] The second work item are data types for new definitions. In some > cases, translation rules will not produce reasonable results (a > good example is the InetAddress family of TCs that try to work > around the lack of proper unions in the SMIv2). While any new > definitions should align to existing definitions as much as > possible, there will be cases where this requires discussion. For > me, the BridgeID is a good example of this kind of discussion and > there is in my view no way to avoid these discussions for cases > where the binary representation implied by the SMIv2 does not match > the more textual XSD approach or where the SMIv2 representation is > specific to SNMP and SMIv2 limitations which do not exist in other > XML based protocols such as NETCONF. > > My understanding was that XSDMI is addressing a] while NETMOD > will work on b] to produce reusable constructs for new > configuration data models. > > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given > FOO-MIB, I can do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be > used to provide access to SMIv2 instrumentation, I believe we > are in trouble. > > Back from the real world to the IETF: There is a work item in > the OPSAWG to do 1). Approach 2) is covered partially in the > NETMOD WG (the YANG->XSD mapping). So from your perspective, > you can say there is no problem as of now. ;-) > > In practice, there is already running code for all of this > and if we do not find a way to make the translation rules > consistent in time (whatever that means in the IETF ;-), I > believe we will see that people use differnet translation > rules and we are going to pay the bill later on. > > There are different solutions possible to deal with this > issue. Some solutions I quickly can come up with (but this is > not meant to be a complete list): > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > translation to XSD is allowed. > > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. > > c) Both translation roads are engineered in parallel and who completes > first wins and the other one has to adapt to the winner, regardless > how painful this will be. > > d) Settle on a single translation approach but make sure that everyone > interested in the other approach is made aware to follow it closely > to ensure that problems are avoided (this is essentially b) without > managed coordination). > > e) Declare that this problem is not worth solving since XML namespaces > will take care of the differences and application writers can deal > with it. > > f) Postpone the problem. > > All I am suggesting is to discuss this issue openly and > fairly on technical grounds with the goal to avoid > incompatible XSD translations of SMIv2 modules. > > /js > The discussion certainly needs to happen and is happening. My understanding is that the approach taken by the XSDMI is assuming e) and is not necessarily targeting NETCONF (or only NETCONF). This is the approved goal in OPSAWG. Do you feel that the namespace differentiation not enough? After all if the approach that strictly reuses what was defined in SMIv2 will not find an immediate applications, and the NETCONF approach will have clear advantages, no harm will be made to the NETCONF DM path. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 03:02:01 2008 Return-Path: X-Original-To: netconf-archive@lists.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 EAEAC3A68D0; Thu, 24 Jul 2008 03:02:00 -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 894793A68D0 for ; Thu, 24 Jul 2008 03:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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 dAqBRMk622nP for ; Thu, 24 Jul 2008 03:01:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8AA983A682E for ; Thu, 24 Jul 2008 03:01:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7F66C001D; Thu, 24 Jul 2008 12:02:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fuTo0JYF+vbT; Thu, 24 Jul 2008 12:02:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 836D9C004C; Thu, 24 Jul 2008 12:02:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4956F673DE5; Thu, 24 Jul 2008 12:02:38 +0200 (CEST) Date: Thu, 24 Jul 2008 12:02:38 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724100238.GB4686@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 11:04:55AM +0200, Romascanu, Dan (Dan) wrote: > My understanding is that the approach taken by the XSDMI is assuming e) > and is not necessarily targeting NETCONF (or only NETCONF). This is the > approved goal in OPSAWG. Do you feel that the namespace differentiation > not enough? After all if the From netconf-bounces@ietf.org Thu Jul 24 03:02:01 2008 Return-Path: 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 EAEAC3A68D0; Thu, 24 Jul 2008 03:02:00 -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 894793A68D0 for ; Thu, 24 Jul 2008 03:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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 dAqBRMk622nP for ; Thu, 24 Jul 2008 03:01:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8AA983A682E for ; Thu, 24 Jul 2008 03:01:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7F66C001D; Thu, 24 Jul 2008 12:02:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fuTo0JYF+vbT; Thu, 24 Jul 2008 12:02:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 836D9C004C; Thu, 24 Jul 2008 12:02:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4956F673DE5; Thu, 24 Jul 2008 12:02:38 +0200 (CEST) Date: Thu, 24 Jul 2008 12:02:38 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080724100238.GB4686@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 11:04:55AM +0200, Romascanu, Dan (Dan) wrote: > My understanding is that the approach taken by the XSDMI is assuming e) > and is not necessarily targeting NETCONF (or only NETCONF). This is the > approved goal in OPSAWG. Do you feel that the namespace differentiation > not enough? After all if the approach that strictly reuses what was > defined in SMIv2 will not find an immediate applications, and the > NETCONF approach will have clear advantages, no harm will be made to the > NETCONF DM path. If there is general agreement that e) is the way to go, then I will shut up and then implementors can enjoy the freedom to choose whatever XSD translation they like most. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf approach that strictly reuses what was > defined in SMIv2 will not find an immediate applications, and the > NETCONF approach will have clear advantages, no harm will be made to the > NETCONF DM path. If there is general agreement that e) is the way to go, then I will shut up and then implementors can enjoy the freedom to choose whatever XSD translation they like most. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 04:10:32 2008 Return-Path: X-Original-To: netconf-archive@lists.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 C4D0E3A6939; Thu, 24 Jul 2008 04:10:32 -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 18B1F3A688C for ; Thu, 24 Jul 2008 04:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] 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 nHWb2IGFroED for ; Thu, 24 Jul 2008 04:10:29 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0087B3A6971 for ; Thu, 24 Jul 2008 04:10:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="128475126" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jul 2008 07:11:08 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241705559" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 07:11:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:10:41 +0200 Message-ID: In-Reply-To: <20080724100238.GB4686@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtdGwyUa0I3hEeSZClB1R9VoFhuAACOyZw References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> <20080724100238.GB4686@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 1:03 PM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Thu, Jul 24, 2008 at 11:04:55AM +0200, Romascanu, Dan (Dan) wrote: > > > My understanding is that the approach taken by the XSDMI is > assuming > > e) and is not necessarily targeting NETCONF (or only > NETCONF). This is > > the approved goal in OPSAWG. Do you feel that the namespace > > differentiation not enough? After all if the approach that strictly > > reuses what was defined in SMIv2 will not find an immediate > > applications, and the NETCONF approach will have clear > advantages, no > > harm will be made to the NETCONF DM path. > > If there is general agreement that e) is the way to go, then > I will shut up and then implementors can enjoy the freedom to > choose whatever XSD translation they like most. > > /js > Just to make clear, I am not expressing an opinion, and certainly I am not giving any 'AD advice' or something similar at this point. I am asking clarification questions, the discussion is open and I suggest that we use email and face to face discussions for folks who will be present in Dublin to try to a sense of consensus (if there is one). Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 04:10:32 2008 Return-Path: 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 C4D0E3A6939; Thu, 24 Jul 2008 04:10:32 -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 18B1F3A688C for ; Thu, 24 Jul 2008 04:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] 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 nHWb2IGFroED for ; Thu, 24 Jul 2008 04:10:29 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 0087B3A6971 for ; Thu, 24 Jul 2008 04:10:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="128475126" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jul 2008 07:11:08 -0400 X-IronPort-AV: E=Sophos;i="4.31,245,1215403200"; d="scan'208";a="241705559" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jul 2008 07:11:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:10:41 +0200 Message-ID: In-Reply-To: <20080724100238.GB4686@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt Thread-Index: AcjtdGwyUa0I3hEeSZClB1R9VoFhuAACOyZw References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> <20080724100238.GB4686@elstar.local> From: "Romascanu, Dan (Dan)" To: Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 1:03 PM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Thu, Jul 24, 2008 at 11:04:55AM +0200, Romascanu, Dan (Dan) wrote: > > > My understanding is that the approach taken by the XSDMI is > assuming > > e) and is not necessarily targeting NETCONF (or only > NETCONF). This is > > the approved goal in OPSAWG. Do you feel that the namespace > > differentiation not enough? After all if the approach that strictly > > reuses what was defined in SMIv2 will not find an immediate > > applications, and the NETCONF approach will have clear > advantages, no > > harm will be made to the NETCONF DM path. > > If there is general agreement that e) is the way to go, then > I will shut up and then implementors can enjoy the freedom to > choose whatever XSD translation they like most. > > /js > Just to make clear, I am not expressing an opinion, and certainly I am not giving any 'AD advice' or something similar at this point. I am asking clarification questions, the discussion is open and I suggest that we use email and face to face discussions for folks who will be present in Dublin to try to a sense of consensus (if there is one). Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 04:34:43 2008 Return-Path: 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 516713A6A20; Thu, 24 Jul 2008 04:34:43 -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 493803A6998 for ; Thu, 24 Jul 2008 04:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 za1yeI6rcmsl for ; Thu, 24 Jul 2008 04:34:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 71ADF3A6957 for ; Thu, 24 Jul 2008 04:34:41 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CA372069D for ; Thu, 24 Jul 2008 13:35:25 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-13-488868fcf491 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0019F20222 for ; Thu, 24 Jul 2008 13:35:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:35:24 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:35:24 +0200 From: David Partain Organization: Ericsson AB To: netconf@ietf.org Date: Thu, 24 Jul 2008 13:35:24 +0200 User-Agent: KMail/1.9.9 References: <20080724083958.GC5161@elstar.local> In-Reply-To: <20080724083958.GC5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807241335.24906.david.partain@ericsson.com> X-OriginalArrivalTime: 24 Jul 2008 11:35:24.0682 (UTC) FILETIME=[5CFEB6A0:01C8ED81] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, On Thursday 24 July 2008 10.39.59 Juergen Schoenwaelder wrote: > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can > do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be used to > provide access to SMIv2 instrumentation, I believe we are in trouble. I agree. I think it's our responsibility as a standards body NOT to get into this trouble if it's avoidable (which I think it is). It seems to me we should able to agree to a single representation of existing SMI datatypes. The trick seems to be deciding that we will... > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. That'd certainly be my preference. Cheers, David _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 04:34:43 2008 Return-Path: X-Original-To: netconf-archive@lists.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 516713A6A20; Thu, 24 Jul 2008 04:34:43 -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 493803A6998 for ; Thu, 24 Jul 2008 04:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 za1yeI6rcmsl for ; Thu, 24 Jul 2008 04:34:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 71ADF3A6957 for ; Thu, 24 Jul 2008 04:34:41 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1CA372069D for ; Thu, 24 Jul 2008 13:35:25 +0200 (CEST) X-AuditID: c1b4fb3e-ae999bb000004ec0-13-488868fcf491 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0019F20222 for ; Thu, 24 Jul 2008 13:35:24 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:35:24 +0200 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:35:24 +0200 From: David Partain Organization: Ericsson AB To: netconf@ietf.org Date: Thu, 24 Jul 2008 13:35:24 +0200 User-Agent: KMail/1.9.9 References: <20080724083958.GC5161@elstar.local> In-Reply-To: <20080724083958.GC5161@elstar.local> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200807241335.24906.david.partain@ericsson.com> X-OriginalArrivalTime: 24 Jul 2008 11:35:24.0682 (UTC) FILETIME=[5CFEB6A0:01C8ED81] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, On Thursday 24 July 2008 10.39.59 Juergen Schoenwaelder wrote: > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can > do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be used to > provide access to SMIv2 instrumentation, I believe we are in trouble. I agree. I think it's our responsibility as a standards body NOT to get into this trouble if it's avoidable (which I think it is). It seems to me we should able to agree to a single representation of existing SMI datatypes. The trick seems to be deciding that we will... > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. That'd certainly be my preference. Cheers, David _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 05:40:08 2008 Return-Path: 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 2163F3A6830; Thu, 24 Jul 2008 05:40:08 -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 26EB93A6830 for ; Thu, 24 Jul 2008 05:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 9oduP9GVXr3V for ; Thu, 24 Jul 2008 05:40:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C10C23A68FC for ; Thu, 24 Jul 2008 05:40:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78F5C21254; Thu, 24 Jul 2008 14:39:38 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-32-4888780a94ff Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4573C20513; Thu, 24 Jul 2008 14:39:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 14:39:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 14:39:37 +0200 Message-ID: <48887808.4020205@ericsson.com> Date: Thu, 24 Jul 2008 14:39:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> In-Reply-To: <20080724083958.GC5161@elstar.local> X-OriginalArrivalTime: 24 Jul 2008 12:39:37.0696 (UTC) FILETIME=[5591FE00:01C8ED8A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I see two immediate users of the datatypes: XSD in new drafts e.g. Netconf Monitoring, and the DSDL mapping. They can either: - Assume solution b) coordinated, consistent datatypes - Start working on draft-wonderful-xsd-datatypes-for-netconf The latter will need extra work, time and authors. balazs Juergen Schoenwaelder wrote: > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > >> So, in your opinion, the specification of the translation rules should >> be the sole (principal?) scope of standardization in this area? Or is >> there a need to optimize the output to get that 'better quality' level >> for some of the commonly used structures? > > There are two work items we have to distinguish: > > a] The first work item is reuse of existing SMIv2 definitions in XML > based protocols and for this we need translation rules. Whether the > rules contain very specific rules to deal with some specific but > frequently occuring constructs is subject to the group defining the > rules. At the end, however, everything has to be automatic since > nobody is going to hand translate stuff that is out there. > > b] The second work item are data types for new definitions. In some > cases, translation rules will not produce reasonable results (a > good example is the InetAddress family of TCs that try to work > around the lack of proper unions in the SMIv2). While any new > definitions should align to existing definitions as much as > possible, there will be cases where this requires discussion. For > me, the BridgeID is a good example of this kind of discussion and > there is in my view no way to avoid these discussions for cases > where the binary representation implied by the SMIv2 does not match > the more textual XSD approach or where the SMIv2 representation is > specific to SNMP and SMIv2 limitations which do not exist in other > XML based protocols such as NETCONF. > > My understanding was that XSDMI is addressing a] while NETMOD will > work on b] to produce reusable constructs for new configuration data > models. > > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can > do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be used to > provide access to SMIv2 instrumentation, I believe we are in trouble. > > Back from the real world to the IETF: There is a work item in the > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG > (the YANG->XSD mapping). So from your perspective, you can say there > is no problem as of now. ;-) > > In practice, there is already running code for all of this and if we > do not find a way to make the translation rules consistent in time > (whatever that means in the IETF ;-), I believe we will see that > people use differnet translation rules and we are going to pay the > bill later on. > > There are different solutions possible to deal with this issue. Some > solutions I quickly can come up with (but this is not meant to be a > complete list): > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > translation to XSD is allowed. > > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. > > c) Both translation roads are engineered in parallel and who completes > first wins and the other one has to adapt to the winner, regardless > how painful this will be. > > d) Settle on a single translation approach but make sure that everyone > interested in the other approach is made aware to follow it closely > to ensure that problems are avoided (this is essentially b) without > managed coordination). > > e) Declare that this problem is not worth solving since XML namespaces > will take care of the differences and application writers can deal > with it. > > f) Postpone the problem. > > All I am suggesting is to discuss this issue openly and fairly on > technical grounds with the goal to avoid incompatible XSD translations > of SMIv2 modules. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 05:40:08 2008 Return-Path: X-Original-To: netconf-archive@lists.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 2163F3A6830; Thu, 24 Jul 2008 05:40:08 -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 26EB93A6830 for ; Thu, 24 Jul 2008 05:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 9oduP9GVXr3V for ; Thu, 24 Jul 2008 05:40:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C10C23A68FC for ; Thu, 24 Jul 2008 05:40:05 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 78F5C21254; Thu, 24 Jul 2008 14:39:38 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-32-4888780a94ff Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4573C20513; Thu, 24 Jul 2008 14:39:38 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 14:39:38 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 14:39:37 +0200 Message-ID: <48887808.4020205@ericsson.com> Date: Thu, 24 Jul 2008 14:39:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , David Harrington , "Natale, Bob" , Sharon Chisholm , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> In-Reply-To: <20080724083958.GC5161@elstar.local> X-OriginalArrivalTime: 24 Jul 2008 12:39:37.0696 (UTC) FILETIME=[5591FE00:01C8ED8A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I see two immediate users of the datatypes: XSD in new drafts e.g. Netconf Monitoring, and the DSDL mapping. They can either: - Assume solution b) coordinated, consistent datatypes - Start working on draft-wonderful-xsd-datatypes-for-netconf The latter will need extra work, time and authors. balazs Juergen Schoenwaelder wrote: > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan (Dan) wrote: > >> So, in your opinion, the specification of the translation rules should >> be the sole (principal?) scope of standardization in this area? Or is >> there a need to optimize the output to get that 'better quality' level >> for some of the commonly used structures? > > There are two work items we have to distinguish: > > a] The first work item is reuse of existing SMIv2 definitions in XML > based protocols and for this we need translation rules. Whether the > rules contain very specific rules to deal with some specific but > frequently occuring constructs is subject to the group defining the > rules. At the end, however, everything has to be automatic since > nobody is going to hand translate stuff that is out there. > > b] The second work item are data types for new definitions. In some > cases, translation rules will not produce reasonable results (a > good example is the InetAddress family of TCs that try to work > around the lack of proper unions in the SMIv2). While any new > definitions should align to existing definitions as much as > possible, there will be cases where this requires discussion. For > me, the BridgeID is a good example of this kind of discussion and > there is in my view no way to avoid these discussions for cases > where the binary representation implied by the SMIv2 does not match > the more textual XSD approach or where the SMIv2 representation is > specific to SNMP and SMIv2 limitations which do not exist in other > XML based protocols such as NETCONF. > > My understanding was that XSDMI is addressing a] while NETMOD will > work on b] to produce reusable constructs for new configuration data > models. > > Excursion to the real world: I am familiar with a particular > implementation that has translation rules to directly translate > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > efforts to specify how to translate YANG->XSD. So given FOO-MIB, I can > do already today: > > 1) FOO-MIB -> FOO-MIB.xsd > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > And the result is not the same. Assuming that NETCONF will be used to > provide access to SMIv2 instrumentation, I believe we are in trouble. > > Back from the real world to the IETF: There is a work item in the > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG > (the YANG->XSD mapping). So from your perspective, you can say there > is no problem as of now. ;-) > > In practice, there is already running code for all of this and if we > do not find a way to make the translation rules consistent in time > (whatever that means in the IETF ;-), I believe we will see that > people use differnet translation rules and we are going to pay the > bill later on. > > There are different solutions possible to deal with this issue. Some > solutions I quickly can come up with (but this is not meant to be a > complete list): > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > translation to XSD is allowed. > > b) Both translations are developed at the same time and we ensure that > things are coordinated and that at the end that the outcome of the > two translation paths is consistent. > > c) Both translation roads are engineered in parallel and who completes > first wins and the other one has to adapt to the winner, regardless > how painful this will be. > > d) Settle on a single translation approach but make sure that everyone > interested in the other approach is made aware to follow it closely > to ensure that problems are avoided (this is essentially b) without > managed coordination). > > e) Declare that this problem is not worth solving since XML namespaces > will take care of the differences and application writers can deal > with it. > > f) Postpone the problem. > > All I am suggesting is to discuss this issue openly and fairly on > technical grounds with the goal to avoid incompatible XSD translations > of SMIv2 modules. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 14:32:19 2008 Return-Path: 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 A81C63A6823; Thu, 24 Jul 2008 14:32:19 -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 407A83A6839 for ; Thu, 24 Jul 2008 14:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] 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 6U6V37T7VQNO for ; Thu, 24 Jul 2008 14:32:18 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 728DC3A6823 for ; Thu, 24 Jul 2008 14:32:18 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 0834076C227; Thu, 24 Jul 2008 23:32:17 +0200 (CEST) Date: Thu, 24 Jul 2008 23:32:12 +0200 (CEST) Message-Id: <20080724.233212.205152387.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080723144932.GC3531@elstar.local> References: <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > So how is inet:host different from what you get out of translating the > YANG inet:host definition into XSD? The inet:host XSD is in fact just an (automatic) translation of the corresponding types from the "inet-types" YANG module. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jul 24 14:32:19 2008 Return-Path: X-Original-To: netconf-archive@lists.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 A81C63A6823; Thu, 24 Jul 2008 14:32:19 -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 407A83A6839 for ; Thu, 24 Jul 2008 14:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] 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 6U6V37T7VQNO for ; Thu, 24 Jul 2008 14:32:18 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 728DC3A6823 for ; Thu, 24 Jul 2008 14:32:18 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 0834076C227; Thu, 24 Jul 2008 23:32:17 +0200 (CEST) Date: Thu, 24 Jul 2008 23:32:12 +0200 (CEST) Message-Id: <20080724.233212.205152387.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080723144932.GC3531@elstar.local> References: <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > So how is inet:host different from what you get out of translating the > YANG inet:host definition into XSD? The inet:host XSD is in fact just an (automatic) translation of the corresponding types from the "inet-types" YANG module. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 01:54:09 2008 Return-Path: X-Original-To: netconf-archive@lists.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 54D6B3A6A8B; Fri, 25 Jul 2008 01:54:09 -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 B60203A6A8B for ; Fri, 25 Jul 2008 01:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6] 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 VBdfXk9AUF6B for ; Fri, 25 Jul 2008 01:54:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B6C013A698F for ; Fri, 25 Jul 2008 01:54:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF1A2C003E; Fri, 25 Jul 2008 10:54:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IelXG8q1jDeg; Fri, 25 Jul 2008 10:53:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80FD3C003D; Fri, 25 Jul 2008 10:53:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74972675641; Fri, 25 Jul 2008 10:53:57 +0200 (CEST) Date: Fri, 25 Jul 2008 10:53:57 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080725085357.GA2924@elstar.local> Mail-Followup-To: Martin Bjorklund , schishol@nortel.com, netconf@ietf.org References: <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> <20080724.233212.205152387.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080724.233212.205152387.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 11:32:12PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > So how is inet:host different from what you get out of translating the > > YANG inet:host definition into XSD? > > The inet:host XSD is in fact just an (automatic) translation of the > corresponding types from the "inet-types" YANG module. So then the differences I see are 'just' version differences. I am still feeling uneasy that we have a non-normative YANG source module that imports other YANG modules, we apply a translation algorithm to it that is under definition, and the resulting XSD output we post for standardization. And alFrom netconf-bounces@ietf.org Fri Jul 25 01:54:09 2008 Return-Path: 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 54D6B3A6A8B; Fri, 25 Jul 2008 01:54:09 -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 B60203A6A8B for ; Fri, 25 Jul 2008 01:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6] 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 VBdfXk9AUF6B for ; Fri, 25 Jul 2008 01:54:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B6C013A698F for ; Fri, 25 Jul 2008 01:54:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF1A2C003E; Fri, 25 Jul 2008 10:54:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IelXG8q1jDeg; Fri, 25 Jul 2008 10:53:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80FD3C003D; Fri, 25 Jul 2008 10:53:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74972675641; Fri, 25 Jul 2008 10:53:57 +0200 (CEST) Date: Fri, 25 Jul 2008 10:53:57 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20080725085357.GA2924@elstar.local> Mail-Followup-To: Martin Bjorklund , schishol@nortel.com, netconf@ietf.org References: <20080723124502.GA3425@elstar.local> <713043CE8B8E1348AF3C546DBE02C1B415945C50@zcarhxm2.corp.nortel.com> <20080723144932.GC3531@elstar.local> <20080724.233212.205152387.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080724.233212.205152387.mbj@tail-f.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jul 24, 2008 at 11:32:12PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > So how is inet:host different from what you get out of translating the > > YANG inet:host definition into XSD? > > The inet:host XSD is in fact just an (automatic) translation of the > corresponding types from the "inet-types" YANG module. So then the differences I see are 'just' version differences. I am still feeling uneasy that we have a non-normative YANG source module that imports other YANG modules, we apply a translation algorithm to it that is under definition, and the resulting XSD output we post for standardization. And all this is done without being described in the document nor is there a clear statement that the XSD is (or is meant to be) identical to other YANG definitions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf l this is done without being described in the document nor is there a clear statement that the XSD is (or is meant to be) identical to other YANG definitions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 02:17:03 2008 Return-Path: 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 1E48A3A699C; Fri, 25 Jul 2008 02:17:03 -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 88D8C3A69DF for ; Fri, 25 Jul 2008 02:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 m-gdC34VYN8U for ; Fri, 25 Jul 2008 02:17:00 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2CA3A689D for ; Fri, 25 Jul 2008 02:17:00 -0700 (PDT) X-Trace: 61715571/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.69 X-SBRS: None X-RemoteIP: 213.116.52.69 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAHY2iUjVdDRF/2dsb2JhbACDXYgQpWED X-IronPort-AV: E=Sophos;i="4.31,252,1215385200"; d="scan'208";a="61715571" X-IP-Direction: IN Received: from 1cust69.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.69]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Jul 2008 10:16:59 +0100 Message-ID: <00d401c8ee2d$f9af1880$0601a8c0@allison> From: "tom.petch" To: , "David B Harrington" References: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG><002b01c8ed00$6467db50$0600a8c0@china.huawei.com> <20080724075549.GB5161@elstar.local> Date: Fri, 25 Jul 2008 09:48:58 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: Sent: Thursday, July 24, 2008 9:55 AM Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > On Wed, Jul 23, 2008 at 04:12:09PM -0400, David B Harrington wrote: > > > I will use the BridgeId definition in YANG-LIB as an example. > > There is not YANG-LIB - but I know what you mean. ;-) > > > BridgeId in RFC4188 is defined to match the binary representation > > pulled from 802.1D spanning tree messages. IETF and IEEE agreed on > > this format. > > bridgeid in YANG-LIB is defined to use a textual formatted string with > > a colon separator instead. (and it uses a "reference" of RFC4188, > > which seems odd) > > So what do you think is the appropriate "faithful to SMIv2" > representation of BridgeId in XML? > > > Which is better? > > Which is more "high-quality"? > > Which is better for directly comparing to the binary values passed in > > the spanning tree BPDU? > > Which one has chosen to diverge so now we have two different XSD > > datatypes? > > Can you explain to me why > represents an IP address in dotted quad notation while it is on the > wire (in SNMP and IP) just a four octet field? Can you explain to me > why the same document represents OIDs in dotted number notation while > they are BER encoded 7bit binary number sequences in SNMP? Can you > answer the above questions for each of these examples? > At the risk of stating the obvious, because the on-the-wire encoding sets out to be different. BER.1, for good reasons, is a binary encoding, XML, for equally good reasons, uses a character encoding, so what is on the wire is bound to be different. We could have preserved the ASN.1 and gone for a different, character-based encoding, but didn't - we chose XML and I think that Bob's I-D reflects that. What should be preserved across the transformation(s), be they SMIv2 to XML or SMIv2 to ........ to XML are the abstract concepts of the data model, the ASN.1-ness and not the on-the-wire encoding. Tom Petch _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 02:17:03 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1E48A3A699C; Fri, 25 Jul 2008 02:17:03 -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 88D8C3A69DF for ; Fri, 25 Jul 2008 02:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 m-gdC34VYN8U for ; Fri, 25 Jul 2008 02:17:00 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2CA3A689D for ; Fri, 25 Jul 2008 02:17:00 -0700 (PDT) X-Trace: 61715571/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.69 X-SBRS: None X-RemoteIP: 213.116.52.69 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAHY2iUjVdDRF/2dsb2JhbACDXYgQpWED X-IronPort-AV: E=Sophos;i="4.31,252,1215385200"; d="scan'208";a="61715571" X-IP-Direction: IN Received: from 1cust69.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.69]) by smtp.pipex.tiscali.co.uk with SMTP; 25 Jul 2008 10:16:59 +0100 Message-ID: <00d401c8ee2d$f9af1880$0601a8c0@allison> From: "tom.petch" To: , "David B Harrington" References: <4915F014FDD99049A9C3A8C1B832004F02DB4BB3@IMCSRV2.MITRE.ORG><002b01c8ed00$6467db50$0600a8c0@china.huawei.com> <20080724075549.GB5161@elstar.local> Date: Fri, 25 Jul 2008 09:48:58 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: Sent: Thursday, July 24, 2008 9:55 AM Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > On Wed, Jul 23, 2008 at 04:12:09PM -0400, David B Harrington wrote: > > > I will use the BridgeId definition in YANG-LIB as an example. > > There is not YANG-LIB - but I know what you mean. ;-) > > > BridgeId in RFC4188 is defined to match the binary representation > > pulled from 802.1D spanning tree messages. IETF and IEEE agreed on > > this format. > > bridgeid in YANG-LIB is defined to use a textual formatted string with > > a colon separator instead. (and it uses a "reference" of RFC4188, > > which seems odd) > > So what do you think is the appropriate "faithful to SMIv2" > representation of BridgeId in XML? > > > Which is better? > > Which is more "high-quality"? > > Which is better for directly comparing to the binary values passed in > > the spanning tree BPDU? > > Which one has chosen to diverge so now we have two different XSD > > datatypes? > > Can you explain to me why > represents an IP address in dotted quad notation while it is on the > wire (in SNMP and IP) just a four octet field? Can you explain to me > why the same document represents OIDs in dotted number notation while > they are BER encoded 7bit binary number sequences in SNMP? Can you > answer the above questions for each of these examples? > At the risk of stating the obvious, because the on-the-wire encoding sets out to be different. BER.1, for good reasons, is a binary encoding, XML, for equally good reasons, uses a character encoding, so what is on the wire is bound to be different. We could have preserved the ASN.1 and gone for a different, character-based encoding, but didn't - we chose XML and I think that Bob's I-D reflects that. What should be preserved across the transformation(s), be they SMIv2 to XML or SMIv2 to ........ to XML are the abstract concepts of the data model, the ASN.1-ness and not the on-the-wire encoding. Tom Petch _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 06:28:18 2008 Return-Path: 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 2385C3A6A9F; Fri, 25 Jul 2008 06:28:18 -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 CFB5F3A6A9F for ; Fri, 25 Jul 2008 06:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jNlGlha1IYlf for ; Fri, 25 Jul 2008 06:28:14 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E37C23A6862 for ; Fri, 25 Jul 2008 06:28:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6PDS9A09817 for ; Fri, 25 Jul 2008 13:28:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Jul 2008 09:27:53 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LA= References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I don't know if I'm suppose to use up a lot of bandwidth on the mailing list to discuss things that are not yet part of the charter, but I wanted to make a make a few comments about Data Change Notifications (configuration changes) prior to the meeting. It needs to be clarified that configuration change notifications get sent out for changes to the running configuration. This potentially means that a bunch of edit-config operations are applied on a candidate configuration to create this change. I suspect this means we need to send multiple change events. I had based the description originally on an implementation that only edited running configuration so I missed this. An open issue is how to ensure that you didn't miss a configuration change event due to throttling. The traditional use of sequence numbers to aid detection of this doesn't work with filtering. Assigning a version number to the entire configuration might be a more effective method. This is easy with a centralized configuration store, but if the configuration is distributed throughout the network element, I don't know how hard this is. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, July 07, 2From netconf-bounces@ietf.org Fri Jul 25 06:28:18 2008 Return-Path: X-Original-To: netconf-archive@lists.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 2385C3A6A9F; Fri, 25 Jul 2008 06:28:18 -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 CFB5F3A6A9F for ; Fri, 25 Jul 2008 06:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 jNlGlha1IYlf for ; Fri, 25 Jul 2008 06:28:14 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id E37C23A6862 for ; Fri, 25 Jul 2008 06:28:12 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6PDS9A09817 for ; Fri, 25 Jul 2008 13:28:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Jul 2008 09:27:53 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LA= References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I don't know if I'm suppose to use up a lot of bandwidth on the mailing list to discuss things that are not yet part of the charter, but I wanted to make a make a few comments about Data Change Notifications (configuration changes) prior to the meeting. It needs to be clarified that configuration change notifications get sent out for changes to the running configuration. This potentially means that a bunch of edit-config operations are applied on a candidate configuration to create this change. I suspect this means we need to send multiple change events. I had based the description originally on an implementation that only edited running configuration so I missed this. An open issue is how to ensure that you didn't miss a configuration change event due to throttling. The traditional use of sequence numbers to aid detection of this doesn't work with filtering. Assigning a version number to the entire configuration might be a more effective method. This is easy with a centralized configuration store, but if the configuration is distributed throughout the network element, I don't know how hard this is. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Monday, July008 5:09 PM To: netconf@ietf.org Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt Hi The following draft defines standard content for NETCONF Notifications, with an aim to support full-lifecycle configuration management. This work was deferred from the original NETCONF Notification protocol work because of the separation of protocol and content and was brought up at the mike (by someone other then the authors) at the last IETF meeting as a gap in our NETCONF solution. We would like to discuss this work at the upcoming meeting in Dublin. Sharon -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Notification Content Author(s) : S. Chisholm, et al. Filename : draft-chisholm-netconf-not-content-00.txt Pages : 29 Date : 2008-07-07 The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information that should be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 07, 2008 5:09 PM To: netconf@ietf.org Subject: [Netconf] FW: I-D Action:draft-chisholm-netconf-not-content-00.txt Hi The following draft defines standard content for NETCONF Notifications, with an aim to support full-lifecycle configuration management. This work was deferred from the original NETCONF Notification protocol work because of the separation of protocol and content and was brought up at the mike (by someone other then the authors) at the last IETF meeting as a gap in our NETCONF solution. We would like to discuss this work at the upcoming meeting in Dublin. Sharon -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 07, 2008 5:00 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Notification Content Author(s) : S. Chisholm, et al. Filename : draft-chisholm-netconf-not-content-00.txt Pages : 29 Date : 2008-07-07 The NETCONF Event Notifications standard specifies the mechanism by which NETCONF clients can subscribe to and receive event notifications. However, with the exception of a timestamp, no standard Notification content was defined. This memo defines a set of information that should be included in all NETCONF notifications, information that should be included based on class of notification and also defines a set of specific notifications to support specific management functions, such as configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 08:58:35 2008 Return-Path: X-Original-To: netconf-archive@lists.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 24D0928C1F6; Fri, 25 Jul 2008 08:58:35 -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 F39D528C1BB for ; Fri, 25 Jul 2008 08:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5YsysNdsSYnN for ; Fri, 25 Jul 2008 08:58:32 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 9518428C1C5 for ; Fri, 25 Jul 2008 08:58:32 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id uDYy1Z0070EPchoA3FyXpt; Fri, 25 Jul 2008 15:58:31 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id uFyU1Z00K4HwxpC8MFyV3z; Fri, 25 Jul 2008 15:58:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=lHTQJM2IAAAA:8 a=j3Z76cjpAAAA:8 a=UIWpuYvt7VhprkW2asUA:9 a=h8CMLffIVrPylsgPyF8A:9 a=o8rBc6b8FqvDyUz7pgOwJAG7aZ0A:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Romascanu, Dan \(Dan\)'" References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> Date: Fri, 25 Jul 2008 11:58:28 -0400 Message-ID: <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080724074509.GA5161@elstar.local> Thread-Index: AcjtYTb5iJ6eE2KDTUSExBI256dS8gBDYEtQ Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The problem is, the tools make some decisions to "improve" the definition rather than provide a faithful translation of the SMIv2 definition. I have not tested the tool's BridgeId translation from the BRIDGE-MIB definition to the tool's output, but I assume you used libsmi to generate the YANG-LIB definition, which changes the format from the IETF/IEEE standardized format to an "improved" proprietary text-based format. If the tools do not provide a faithful translation of the standard, then I do not think we should rely on the tools to provide the "standard" translation. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 3:45 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > > > So I assume that there are or will be in XSDMI corresponding > > translations of the RFC4001 TCs, right? > > There are tools out there translate everything you can define in SMIv2 > to XSD by means of relatively simple translation rules. There is IMHO > no point in hand translating selected TCs. Instead, you have to > specify the translation rules and everything falls out from that. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 08:58:35 2008 Return-Path: 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 24D0928C1F6; Fri, 25 Jul 2008 08:58:35 -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 F39D528C1BB for ; Fri, 25 Jul 2008 08:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5YsysNdsSYnN for ; Fri, 25 Jul 2008 08:58:32 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 9518428C1C5 for ; Fri, 25 Jul 2008 08:58:32 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id uDYy1Z0070EPchoA3FyXpt; Fri, 25 Jul 2008 15:58:31 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id uFyU1Z00K4HwxpC8MFyV3z; Fri, 25 Jul 2008 15:58:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=LwEgQN8X54kA:10 a=BmOEMCpA8McA:10 a=lHTQJM2IAAAA:8 a=j3Z76cjpAAAA:8 a=UIWpuYvt7VhprkW2asUA:9 a=h8CMLffIVrPylsgPyF8A:9 a=o8rBc6b8FqvDyUz7pgOwJAG7aZ0A:4 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Romascanu, Dan \(Dan\)'" References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> Date: Fri, 25 Jul 2008 11:58:28 -0400 Message-ID: <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20080724074509.GA5161@elstar.local> Thread-Index: AcjtYTb5iJ6eE2KDTUSExBI256dS8gBDYEtQ Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, The problem is, the tools make some decisions to "improve" the definition rather than provide a faithful translation of the SMIv2 definition. I have not tested the tool's BridgeId translation from the BRIDGE-MIB definition to the tool's output, but I assume you used libsmi to generate the YANG-LIB definition, which changes the format from the IETF/IEEE standardized format to an "improved" proprietary text-based format. If the tools do not provide a faithful translation of the standard, then I do not think we should rely on the tools to provide the "standard" translation. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, July 24, 2008 3:45 AM > To: Romascanu, Dan (Dan) > Cc: David Harrington; Natale, Bob; Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > On Wed, Jul 23, 2008 at 10:36:27PM +0200, Romascanu, Dan (Dan) wrote: > > > So I assume that there are or will be in XSDMI corresponding > > translations of the RFC4001 TCs, right? > > There are tools out there translate everything you can define in SMIv2 > to XSD by means of relatively simple translation rules. There is IMHO > no point in hand translating selected TCs. Instead, you have to > specify the translation rules and everything falls out from that. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 10:56:13 2008 Return-Path: X-Original-To: netconf-archive@lists.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 2086B3A6861; Fri, 25 Jul 2008 10:56:13 -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 93C1F3A6861 for ; Fri, 25 Jul 2008 10:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=1.044, 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 fgUJ6K6MAPDh for ; Fri, 25 Jul 2008 10:56:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 62BCD3A6816 for ; Fri, 25 Jul 2008 10:56:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C1D6C0039; Fri, 25 Jul 2008 19:56:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zIkjuqzvPuHD; Fri, 25 Jul 2008 19:56:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BA5CC0041; Fri, 25 Jul 2008 19:56:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C23206763F6; Fri, 25 Jul 2008 19:56:03 +0200 (CEST) Date: Fri, 25 Jul 2008 19:56:03 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080725175603.GA4412@elstar.local> Mail-Followup-To: David Harrington , "'Romascanu, Dan (Dan)'" , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jul 25, 2008 at 11:58:28AM -0400, David Harrington wrote: > The problem is, the tools make some decisions to "improve" the > definition rather than provide a faithful translation of the SMIv2 > definition. I will ignore the word 'faithful' until someone provides a decent definition of it. > I have not tested the tool's BridgeId translation from the BRIDGE-MIB > definition to the tool's output, but I assume you used libsmi to > generate the YANG-LIB definitFrom netconf-bounces@ietf.org Fri Jul 25 10:56:13 2008 Return-Path: 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 2086B3A6861; Fri, 25 Jul 2008 10:56:13 -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 93C1F3A6861 for ; Fri, 25 Jul 2008 10:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=1.044, 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 fgUJ6K6MAPDh for ; Fri, 25 Jul 2008 10:56:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 62BCD3A6816 for ; Fri, 25 Jul 2008 10:56:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C1D6C0039; Fri, 25 Jul 2008 19:56:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zIkjuqzvPuHD; Fri, 25 Jul 2008 19:56:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BA5CC0041; Fri, 25 Jul 2008 19:56:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C23206763F6; Fri, 25 Jul 2008 19:56:03 +0200 (CEST) Date: Fri, 25 Jul 2008 19:56:03 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080725175603.GA4412@elstar.local> Mail-Followup-To: David Harrington , "'Romascanu, Dan (Dan)'" , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jul 25, 2008 at 11:58:28AM -0400, David Harrington wrote: > The problem is, the tools make some decisions to "improve" the > definition rather than provide a faithful translation of the SMIv2 > definition. I will ignore the word 'faithful' until someone provides a decent definition of it. > I have not tested the tool's BridgeId translation from the BRIDGE-MIB > definition to the tool's output, but I assume you used libsmi to > generate the YANG-LIB definition, wion, which changes the format from the > IETF/IEEE standardized format to an "improved" proprietary text-based > format. You guessed wrong. But the whole point is that the SMIv2 BridgeId defines a binary reprentation; in XML you have to render binary data into something textual. SMIv2 does not define a textual rendering for BridgeId. I defined one which I thought matches existing CLIs and what operators are used to. If you do not like it, make a constructive counter proposal - otherwise we are wasting energy. Yours faithfully, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf hich changes the format from the > IETF/IEEE standardized format to an "improved" proprietary text-based > format. You guessed wrong. But the whole point is that the SMIv2 BridgeId defines a binary reprentation; in XML you have to render binary data into something textual. SMIv2 does not define a textual rendering for BridgeId. I defined one which I thought matches existing CLIs and what operators are used to. If you do not like it, make a constructive counter proposal - otherwise we are wasting energy. Yours faithfully, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 11:26:27 2008 Return-Path: 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 1BB8D3A6929; Fri, 25 Jul 2008 11:26:27 -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 D379A3A685F for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0cmBtjijPfWn for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 77AEF3A698A for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id uHhC1Z00J1GhbT851JRK95; Fri, 25 Jul 2008 18:25:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id uJRS1Z0014HwxpC3TJRSWZ; Fri, 25 Jul 2008 18:25:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=t40o1_5MdO8aR_ek8S8A:9 a=mIv3QzdzArL5BmQ4vP4A:9 a=dleqMoohQfIN5IQiTaYA:7 a=OY6S40aIMTNJKDsN5HVl6EsGCRwA:4 a=OnwlB_Fi9scA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , , References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> Date: Fri, 25 Jul 2008 14:25:25 -0400 Message-ID: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjtioCqQYS/EgQBScqLI7Te+IDEUQA5wUbw In-Reply-To: <48887808.4020205@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Netconf] SMIv2->XSD X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I have copied this to the netmod and opsawg WG mailing lists, since that is where datatype libraries should be discussed. You only see two immediate uses for SMIv2 datatypes in XSD because you only work on netconf standards. How about datatypes for my SNMP NMS that has an XML/XSD-capable database? Why do I have to wait for the Netmod WG to finish designing a language **specifically for use with netconf** before I can have a standard XSD to work with my SMIv2 datatypes in an SNMP-focused application? How about the implementing netconf that needs/wants to define XML-based datamodels to use with netconf, as suggested by RFC4741, and the company wants to leverage all the SMIv2 MIB support it already has available in its products and wants a standardized translation of SMIv2 datatypes NOW, not in 3-5 more years. Real world: the IETF network management world does not revolve around YANG. For 20 years, it has revolved around SMI datatypes, not YANG datatypes. XSDMI is an OPSAWG work item. We have already had this discussion mutliple times, and reached consensus to do XSDMI independent of YANG, but with an effort to coordinate with YANG. XSDMI is just about ready for WGLC. Netmod WG is finally going to have its first WG meeting. Netmod WG will not realistically finish anytime soon. And the IESG might eventually decide to not approve netmod's YANG language as a standard. So why does the whole SNMP community need to wait for SMIv2->YANG->XSD? If the available tools generate SMIv2->XSD translations that are valid, and the tools generate SMIv2->YANG->XSD translations that are valid but different, then either the YANG translation rules got it wrong or the YANG tools are trying to solve a different problam than the SMIv2->XSD translation. If I want a direct translation from SMIv2->XSD, why do I have to use YANG tools to do this? Juergen's suggested approaches include b) which is "coordinated" and c) which is "painful". I think this is a false characterization. b) is "painful" to those who have to wait possibly much longer for standard datatypes, especially for non-netconf applications, and c) and d) still have "coordination" so that the result is consistent. XSDMI has already slowed down its work by months to deliberately coordinate its work with the YANG datatypes work, so the two are very close already. Why don't we eliminate YANG-LIB and DSDL datatype work from netmod, and standardize SMIv2 "faithful" datatypes (i.e., with no netconf-specific "improvements") in XSDMI/OPSAWG (possibly using translation rules rather than hand translations) and then netmod (YANG, XML-on-the-wire, and the DSDL mapping) can use the OPSAWG standard datatype library? That way, a standard datatypes library could be available much sooner for applicability to netconf, non-netconf, netmod and non-netmod uses rather than making everybody wait for netmod. If you are convinced that netmod will add some specific requirements that we don't even know about yet, then let's not make XSDMI and the SNMP community and the non-YANG Netconf community wait for netmod to decide what those are since they are obviously not requirements of SMIv2, and XSDMI is all about SMIv2, not netmod. dbh > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Thursday, July 24, 2008 8:40 AM > To: Romascanu, Dan (Dan); David Harrington; Natale, Bob; > Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello, > I see two immediate users of the datatypes: XSD in new drafts > e.g. Netconf Monitoring, and the > DSDL mapping. They can either: > - Assume solution b) coordinated, consistent datatypes > - Start working on draft-wonderful-xsd-datatypes-for-netconf > The latter will need extra work, time and authors. > balazs > > Juergen Schoenwaelder wrote: > > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan > (Dan) wrote: > > > >> So, in your opinion, the specification of the translation > rules should > >> be the sole (principal?) scope of standardization in this > area? Or is > >> there a need to optimize the output to get that 'better > quality' level > >> for some of the commonly used structures? > > > > There are two work items we have to distinguish: > > > > a] The first work item is reuse of existing SMIv2 definitions in XML > > based protocols and for this we need translation rules. > Whether the > > rules contain very specific rules to deal with some specific but > > frequently occuring constructs is subject to the group > defining the > > rules. At the end, however, everything has to be automatic since > > nobody is going to hand translate stuff that is out there. > > > > b] The second work item are data types for new definitions. In some > > cases, translation rules will not produce reasonable results (a > > good example is the InetAddress family of TCs that try to work > > around the lack of proper unions in the SMIv2). While any new > > definitions should align to existing definitions as much as > > possible, there will be cases where this requires discussion. For > > me, the BridgeID is a good example of this kind of discussion and > > there is in my view no way to avoid these discussions for cases > > where the binary representation implied by the SMIv2 > does not match > > the more textual XSD approach or where the SMIv2 > representation is > > specific to SNMP and SMIv2 limitations which do not > exist in other > > XML based protocols such as NETCONF. > > > > My understanding was that XSDMI is addressing a] while NETMOD will > > work on b] to produce reusable constructs for new configuration data > > models. > > > > Excursion to the real world: I am familiar with a particular > > implementation that has translation rules to directly translate > > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > > efforts to specify how to translate YANG->XSD. So given > FOO-MIB, I can > > do already today: > > > > 1) FOO-MIB -> FOO-MIB.xsd > > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > > > And the result is not the same. Assuming that NETCONF will > be used to > > provide access to SMIv2 instrumentation, I believe we are > in trouble. > > > > Back from the real world to the IETF: There is a work item in the > > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG > > (the YANG->XSD mapping). So from your perspective, you can say there > > is no problem as of now. ;-) > > > > In practice, there is already running code for all of this and if we > > do not find a way to make the translation rules consistent in time > > (whatever that means in the IETF ;-), I believe we will see that > > people use differnet translation rules and we are going to pay the > > bill later on. > > > > There are different solutions possible to deal with this issue. Some > > solutions I quickly can come up with (but this is not meant to be a > > complete list): > > > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > > translation to XSD is allowed. > > > > b) Both translations are developed at the same time and we > ensure that > > things are coordinated and that at the end that the > outcome of the > > two translation paths is consistent. > > > > c) Both translation roads are engineered in parallel and > who completes > > first wins and the other one has to adapt to the winner, > regardless > > how painful this will be. > > > > d) Settle on a single translation approach but make sure > that everyone > > interested in the other approach is made aware to follow > it closely > > to ensure that problems are avoided (this is essentially > b) without > > managed coordination). > > > > e) Declare that this problem is not worth solving since XML > namespaces > > will take care of the differences and application > writers can deal > > with it. > > > > f) Postpone the problem. > > > > All I am suggesting is to discuss this issue openly and fairly on > > technical grounds with the goal to avoid incompatible XSD > translations > > of SMIv2 modules. > > > > /js > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 11:26:27 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1BB8D3A6929; Fri, 25 Jul 2008 11:26:27 -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 D379A3A685F for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0cmBtjijPfWn for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 77AEF3A698A for ; Fri, 25 Jul 2008 11:26:25 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id uHhC1Z00J1GhbT851JRK95; Fri, 25 Jul 2008 18:25:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id uJRS1Z0014HwxpC3TJRSWZ; Fri, 25 Jul 2008 18:25:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=t40o1_5MdO8aR_ek8S8A:9 a=mIv3QzdzArL5BmQ4vP4A:9 a=dleqMoohQfIN5IQiTaYA:7 a=OY6S40aIMTNJKDsN5HVl6EsGCRwA:4 a=OnwlB_Fi9scA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , , References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> Date: Fri, 25 Jul 2008 14:25:25 -0400 Message-ID: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjtioCqQYS/EgQBScqLI7Te+IDEUQA5wUbw In-Reply-To: <48887808.4020205@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Netconf] SMIv2->XSD X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I have copied this to the netmod and opsawg WG mailing lists, since that is where datatype libraries should be discussed. You only see two immediate uses for SMIv2 datatypes in XSD because you only work on netconf standards. How about datatypes for my SNMP NMS that has an XML/XSD-capable database? Why do I have to wait for the Netmod WG to finish designing a language **specifically for use with netconf** before I can have a standard XSD to work with my SMIv2 datatypes in an SNMP-focused application? How about the implementing netconf that needs/wants to define XML-based datamodels to use with netconf, as suggested by RFC4741, and the company wants to leverage all the SMIv2 MIB support it already has available in its products and wants a standardized translation of SMIv2 datatypes NOW, not in 3-5 more years. Real world: the IETF network management world does not revolve around YANG. For 20 years, it has revolved around SMI datatypes, not YANG datatypes. XSDMI is an OPSAWG work item. We have already had this discussion mutliple times, and reached consensus to do XSDMI independent of YANG, but with an effort to coordinate with YANG. XSDMI is just about ready for WGLC. Netmod WG is finally going to have its first WG meeting. Netmod WG will not realistically finish anytime soon. And the IESG might eventually decide to not approve netmod's YANG language as a standard. So why does the whole SNMP community need to wait for SMIv2->YANG->XSD? If the available tools generate SMIv2->XSD translations that are valid, and the tools generate SMIv2->YANG->XSD translations that are valid but different, then either the YANG translation rules got it wrong or the YANG tools are trying to solve a different problam than the SMIv2->XSD translation. If I want a direct translation from SMIv2->XSD, why do I have to use YANG tools to do this? Juergen's suggested approaches include b) which is "coordinated" and c) which is "painful". I think this is a false characterization. b) is "painful" to those who have to wait possibly much longer for standard datatypes, especially for non-netconf applications, and c) and d) still have "coordination" so that the result is consistent. XSDMI has already slowed down its work by months to deliberately coordinate its work with the YANG datatypes work, so the two are very close already. Why don't we eliminate YANG-LIB and DSDL datatype work from netmod, and standardize SMIv2 "faithful" datatypes (i.e., with no netconf-specific "improvements") in XSDMI/OPSAWG (possibly using translation rules rather than hand translations) and then netmod (YANG, XML-on-the-wire, and the DSDL mapping) can use the OPSAWG standard datatype library? That way, a standard datatypes library could be available much sooner for applicability to netconf, non-netconf, netmod and non-netmod uses rather than making everybody wait for netmod. If you are convinced that netmod will add some specific requirements that we don't even know about yet, then let's not make XSDMI and the SNMP community and the non-YANG Netconf community wait for netmod to decide what those are since they are obviously not requirements of SMIv2, and XSDMI is all about SMIv2, not netmod. dbh > -----Original Message----- > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] > Sent: Thursday, July 24, 2008 8:40 AM > To: Romascanu, Dan (Dan); David Harrington; Natale, Bob; > Sharon Chisholm; netconf@ietf.org > Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt > > Hello, > I see two immediate users of the datatypes: XSD in new drafts > e.g. Netconf Monitoring, and the > DSDL mapping. They can either: > - Assume solution b) coordinated, consistent datatypes > - Start working on draft-wonderful-xsd-datatypes-for-netconf > The latter will need extra work, time and authors. > balazs > > Juergen Schoenwaelder wrote: > > On Thu, Jul 24, 2008 at 09:53:45AM +0200, Romascanu, Dan > (Dan) wrote: > > > >> So, in your opinion, the specification of the translation > rules should > >> be the sole (principal?) scope of standardization in this > area? Or is > >> there a need to optimize the output to get that 'better > quality' level > >> for some of the commonly used structures? > > > > There are two work items we have to distinguish: > > > > a] The first work item is reuse of existing SMIv2 definitions in XML > > based protocols and for this we need translation rules. > Whether the > > rules contain very specific rules to deal with some specific but > > frequently occuring constructs is subject to the group > defining the > > rules. At the end, however, everything has to be automatic since > > nobody is going to hand translate stuff that is out there. > > > > b] The second work item are data types for new definitions. In some > > cases, translation rules will not produce reasonable results (a > > good example is the InetAddress family of TCs that try to work > > around the lack of proper unions in the SMIv2). While any new > > definitions should align to existing definitions as much as > > possible, there will be cases where this requires discussion. For > > me, the BridgeID is a good example of this kind of discussion and > > there is in my view no way to avoid these discussions for cases > > where the binary representation implied by the SMIv2 > does not match > > the more textual XSD approach or where the SMIv2 > representation is > > specific to SNMP and SMIv2 limitations which do not > exist in other > > XML based protocols such as NETCONF. > > > > My understanding was that XSDMI is addressing a] while NETMOD will > > work on b] to produce reusable constructs for new configuration data > > models. > > > > Excursion to the real world: I am familiar with a particular > > implementation that has translation rules to directly translate > > SMIv2->XSD and SMIv2->YANG. Furthermore, there are tools and IETF > > efforts to specify how to translate YANG->XSD. So given > FOO-MIB, I can > > do already today: > > > > 1) FOO-MIB -> FOO-MIB.xsd > > 2) FOO-MIB -> FOO-MIB.yang -> FOO-MIB.xsd > > > > And the result is not the same. Assuming that NETCONF will > be used to > > provide access to SMIv2 instrumentation, I believe we are > in trouble. > > > > Back from the real world to the IETF: There is a work item in the > > OPSAWG to do 1). Approach 2) is covered partially in the NETMOD WG > > (the YANG->XSD mapping). So from your perspective, you can say there > > is no problem as of now. ;-) > > > > In practice, there is already running code for all of this and if we > > do not find a way to make the translation rules consistent in time > > (whatever that means in the IETF ;-), I believe we will see that > > people use differnet translation rules and we are going to pay the > > bill later on. > > > > There are different solutions possible to deal with this issue. Some > > solutions I quickly can come up with (but this is not meant to be a > > complete list): > > > > a) Translation of SMIv2 to YANG is simply forbitten, only the direct > > translation to XSD is allowed. > > > > b) Both translations are developed at the same time and we > ensure that > > things are coordinated and that at the end that the > outcome of the > > two translation paths is consistent. > > > > c) Both translation roads are engineered in parallel and > who completes > > first wins and the other one has to adapt to the winner, > regardless > > how painful this will be. > > > > d) Settle on a single translation approach but make sure > that everyone > > interested in the other approach is made aware to follow > it closely > > to ensure that problems are avoided (this is essentially > b) without > > managed coordination). > > > > e) Declare that this problem is not worth solving since XML > namespaces > > will take care of the differences and application > writers can deal > > with it. > > > > f) Postpone the problem. > > > > All I am suggesting is to discuss this issue openly and fairly on > > technical grounds with the goal to avoid incompatible XSD > translations > > of SMIv2 modules. > > > > /js > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > TSP System Manager > ECN: 831 7320 Fax: +36 1 4377792 > Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 11:41:05 2008 Return-Path: X-Original-To: netconf-archive@lists.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 6F5DE3A69A9; Fri, 25 Jul 2008 11:41:05 -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 EFBBE3A69A9 for ; Fri, 25 Jul 2008 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 h7oQxbf-bpwj for ; Fri, 25 Jul 2008 11:41:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1ADE03A685F for ; Fri, 25 Jul 2008 11:41:02 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id D9A2476C22D; Fri, 25 Jul 2008 20:41:04 +0200 (CEST) Date: Fri, 25 Jul 2008 20:41:02 +0200 (CEST) Message-Id: <20080725.204102.267564193.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080725085357.GA2924@elstar.local> References: <20080723144932.GC3531@elstar.local> <20080724.233212.205152387.mbj@tail-f.com> <20080725085357.GA2924@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I am still feeling uneasy that we have a non-normative YANG source > module that imports other YANG modules, we apply a translation > algorithm to it that is under definition, and the resulting XSD output > we post for standardization. And all this is done without being > described in the document nor is there a clear statement that the XSD > is (or is meant to be) identical to other YANG definitions. Agreed. An XML-version of "host" (union of domainname, ipv4, ipv6) is needed now for the monitoring draft. Do you have a suggestion for how to solve this? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 11:41:05 2008 Return-Path: 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 6F5DE3A69A9; Fri, 25 Jul 2008 11:41:05 -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 EFBBE3A69A9 for ; Fri, 25 Jul 2008 11:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 h7oQxbf-bpwj for ; Fri, 25 Jul 2008 11:41:03 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1ADE03A685F for ; Fri, 25 Jul 2008 11:41:02 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id D9A2476C22D; Fri, 25 Jul 2008 20:41:04 +0200 (CEST) Date: Fri, 25 Jul 2008 20:41:02 +0200 (CEST) Message-Id: <20080725.204102.267564193.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20080725085357.GA2924@elstar.local> References: <20080723144932.GC3531@elstar.local> <20080724.233212.205152387.mbj@tail-f.com> <20080725085357.GA2924@elstar.local> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I am still feeling uneasy that we have a non-normative YANG source > module that imports other YANG modules, we apply a translation > algorithm to it that is under definition, and the resulting XSD output > we post for standardization. And all this is done without being > described in the document nor is there a clear statement that the XSD > is (or is meant to be) identical to other YANG definitions. Agreed. An XML-version of "host" (union of domainname, ipv4, ipv6) is needed now for the monitoring draft. Do you have a suggestion for how to solve this? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 11:46:27 2008 Return-Path: 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 D829E28C172; Fri, 25 Jul 2008 11:46:27 -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 25AC228C16A for ; Fri, 25 Jul 2008 11:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] 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 Q8n-wL88SFx9 for ; Fri, 25 Jul 2008 11:46:26 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 24AE728C172 for ; Fri, 25 Jul 2008 11:46:26 -0700 (PDT) Received: (qmail 46314 invoked from network); 25 Jul 2008 18:46:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 18:46:22 -0000 X-YMail-OSG: Y5DOu6MVM1kEEqmhJs3GlGC3HM9c51a0RVCLQZOshZDEpInHJKwDhXYSn43aMNhN5Wmj.WotyjjdWv04HvduQnCMM4yRY.UY7dWXtv3gFQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A1F7B.8050502@netconfcentral.com> Date: Fri, 25 Jul 2008 11:46:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Harrington , "'Romascanu, Dan (Dan)'" , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> <20080725175603.GA4412@elstar.local> In-Reply-To: <20080725175603.GA4412@elstar.local> Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Jul 25, 2008 at 11:58:28AM -0400, David Harrington wrote: > >> The problem is, the tools make some decisions to "improve" the >> definition rather than provide a faithful translation of the SMIv2 >> definition. > > I will ignore the word 'faithful' until someone provides a decent > definition of it. > >> I have not tested the tool's BridgeId translation from the BRIDGE-MIB >> definition to the tool's output, but I assume you used libsmi to >> generate the YANG-LIB definition, which changes the format from the >> IETF/IEEE standardized format to an "improved" proprietary text-based >> format. > > You guessed wrong. But the whole point is that the SMIv2 BridgeId > defines a binary reprentation; in XML you have to render binary data > into something textual. SMIv2 does not define a textual rendering for > BridgeId. I defined one which I thought matches existing CLIs and what > operators are used to. If you doFrom netconf-bounces@ietf.org Fri Jul 25 11:46:27 2008 Return-Path: X-Original-To: netconf-archive@lists.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 D829E28C172; Fri, 25 Jul 2008 11:46:27 -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 25AC228C16A for ; Fri, 25 Jul 2008 11:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] 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 Q8n-wL88SFx9 for ; Fri, 25 Jul 2008 11:46:26 -0700 (PDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 24AE728C172 for ; Fri, 25 Jul 2008 11:46:26 -0700 (PDT) Received: (qmail 46314 invoked from network); 25 Jul 2008 18:46:23 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 25 Jul 2008 18:46:22 -0000 X-YMail-OSG: Y5DOu6MVM1kEEqmhJs3GlGC3HM9c51a0RVCLQZOshZDEpInHJKwDhXYSn43aMNhN5Wmj.WotyjjdWv04HvduQnCMM4yRY.UY7dWXtv3gFQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <488A1F7B.8050502@netconfcentral.com> Date: Fri, 25 Jul 2008 11:46:19 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Harrington , "'Romascanu, Dan (Dan)'" , "'Natale, Bob'" , 'Sharon Chisholm' , netconf@ietf.org References: <003001c8ed03$6f0e6bc0$0600a8c0@china.huawei.com> <20080724074509.GA5161@elstar.local> <00bf01c8ee6f$48a3e420$0600a8c0@china.huawei.com> <20080725175603.GA4412@elstar.local> In-Reply-To: <20080725175603.GA4412@elstar.local> Subject: Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Jul 25, 2008 at 11:58:28AM -0400, David Harrington wrote: > >> The problem is, the tools make some decisions to "improve" the >> definition rather than provide a faithful translation of the SMIv2 >> definition. > > I will ignore the word 'faithful' until someone provides a decent > definition of it. > >> I have not tested the tool's BridgeId translation from the BRIDGE-MIB >> definition to the tool's output, but I assume you used libsmi to >> generate the YANG-LIB definition, which changes the format from the >> IETF/IEEE standardized format to an "improved" proprietary text-based >> format. > > You guessed wrong. But the whole point is that the SMIv2 BridgeId > defines a binary reprentation; in XML you have to render binary data > into something textual. SMIv2 does not define a textual rendering for > BridgeId. I defined one which I thought matches existing CLIs and what > operators are used to. If not like it, make a constructive > counter proposal - otherwise we are wasting energy. > It could be encoded as hexBinary or base64Binary, but... IMO, this entire approach to SMIv2 data type usage is broken because the definitions are moving to a different module. In YANG, that's a big deal. In XSD conversion, it means tools will need to be hard-wired to change IMPORTS for certain 'special' TCs, and hide the real definitions from use. For example, any translated MIB that uses InetAddress will be importing it from INET-ADDRESS-MIB. Any new module that uses the new data types can not really be integrated with existing modules that do not use the new versions. IMO, the data types in the libsmi translated INET-ADDRESS-MIB.yang follow the SMIv2 translation as faithfully as possible, and the correct module name is maintained. An algorithmic approach to SMIv2 integration is needed, that describes how to convert every data type and every TC that has ever been written, or could be written. This is probably too hard to standardize, even though there is running code that can do it. Since the IETF is intent on pursuing this work, at least consider this problem. > Yours faithfully, > > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf you do not like it, make a constructive > counter proposal - otherwise we are wasting energy. > It could be encoded as hexBinary or base64Binary, but... IMO, this entire approach to SMIv2 data type usage is broken because the definitions are moving to a different module. In YANG, that's a big deal. In XSD conversion, it means tools will need to be hard-wired to change IMPORTS for certain 'special' TCs, and hide the real definitions from use. For example, any translated MIB that uses InetAddress will be importing it from INET-ADDRESS-MIB. Any new module that uses the new data types can not really be integrated with existing modules that do not use the new versions. IMO, the data types in the libsmi translated INET-ADDRESS-MIB.yang follow the SMIv2 translation as faithfully as possible, and the correct module name is maintained. An algorithmic approach to SMIv2 integration is needed, that describes how to convert every data type and every TC that has ever been written, or could be written. This is probably too hard to standardize, even though there is running code that can do it. Since the IETF is intent on pursuing this work, at least consider this problem. > Yours faithfully, > > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 13:38:20 2008 Return-Path: X-Original-To: netconf-archive@lists.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 C915E3A68C3; Fri, 25 Jul 2008 13:38:20 -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 578893A68C3; Fri, 25 Jul 2008 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 j-AHk2zhfjYB; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 850CD3A68AE; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 03BC476C22D; Fri, 25 Jul 2008 22:38:20 +0200 (CEST) Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST) Message-Id: <20080725.223817.240580203.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> References: <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: opsawg@ietf.org, netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [OPSAWG] SMIv2->XSD X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "David Harrington" wrote: > How about the implementing netconf that needs/wants > to define XML-based datamodels to use with netconf, as suggested by > RFC4741, and the company wants to leverage all the SMIv2 MIB support > it already has available in its products and wants a standardized > translation of SMIv2 datatypes NOW, not in 3-5 more years. Several companies already do this, in proprietary ways. But the datatype translation is just one part (maybe the easy one). Other things to consider for a standard SMIv2->XML mapping are: what does the XML structure look like? What is the top-level element for a given MIB? Which namespace URI is used? How are INDEXes encoded? How are INDEXes in foreign tables encoded? How is RowStatus handled? How is StorageType handled? I think it has been said before, but I would rather see a mapping of SMIv2 (types and structure) to XML, than XSD. If there was a mapping to XML, tools could generate compliant XSD, RNG, or YANG. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jul 25 13:38:20 2008 Return-Path: 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 C915E3A68C3; Fri, 25 Jul 2008 13:38:20 -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 578893A68C3; Fri, 25 Jul 2008 13:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 j-AHk2zhfjYB; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 850CD3A68AE; Fri, 25 Jul 2008 13:38:19 -0700 (PDT) Received: from localhost (81-236-236-254-no38.tbcn.telia.com [81.236.236.254]) by mail.tail-f.com (Postfix) with ESMTPSA id 03BC476C22D; Fri, 25 Jul 2008 22:38:20 +0200 (CEST) Date: Fri, 25 Jul 2008 22:38:17 +0200 (CEST) Message-Id: <20080725.223817.240580203.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> References: <20080724083958.GC5161@elstar.local> <48887808.4020205@ericsson.com> <000101c8ee83$cf4a7930$0600a8c0@china.huawei.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: opsawg@ietf.org, netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [OPSAWG] SMIv2->XSD X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "David Harrington" wrote: > How about the implementing netconf that needs/wants > to define XML-based datamodels to use with netconf, as suggested by > RFC4741, and the company wants to leverage all the SMIv2 MIB support > it already has available in its products and wants a standardized > translation of SMIv2 datatypes NOW, not in 3-5 more years. Several companies already do this, in proprietary ways. But the datatype translation is just one part (maybe the easy one). Other things to consider for a standard SMIv2->XML mapping are: what does the XML structure look like? What is the top-level element for a given MIB? Which namespace URI is used? How are INDEXes encoded? How are INDEXes in foreign tables encoded? How is RowStatus handled? How is StorageType handled? I think it has been said before, but I would rather see a mapping of SMIv2 (types and structure) to XML, than XSD. If there was a mapping to XML, tools could generate compliant XSD, RNG, or YANG. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jul 28 00:59:16 2008 Return-Path: X-Original-To: netconf-archive@lists.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 BE6E328C1D1; Mon, 28 Jul 2008 00:59:16 -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 465523A6A5B; Sun, 27 Jul 2008 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hHqJRCpGDf3k; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 71F953A685C; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKnY021333; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKlc021327; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 01:15:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 01:13:50 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2wK9u9bgG6JDzkACmju30A== References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Jul 2008 05:15:20.0419 (UTC) FILETIME=[EE3F5330:01C8F070] X-Mailman-Approved-At: Mon, 28 Jul 2008 00:59:15 -0700 Cc: mib2rdml@ietf.org Subject: [Netconf] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076642729==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0076642729== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F070.BAA7AC6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted an updated version (-03) of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", via the Internet-Drafts submission tool, but it will likely not get processed until following IETF-72. =20 In the meantime, interested parties can download a copy from: http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x sd-03.txt =2From netconf-bounces@ietf.org Mon Jul 28 00:59:16 2008 Return-Path: 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 BE6E328C1D1; Mon, 28 Jul 2008 00:59:16 -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 465523A6A5B; Sun, 27 Jul 2008 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hHqJRCpGDf3k; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 71F953A685C; Sun, 27 Jul 2008 22:15:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKnY021333; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m6S5FKlc021327; Mon, 28 Jul 2008 01:15:20 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 01:15:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 01:13:50 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02E47157@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted Thread-Index: AchshrU9Eh9mtU+dQEyJvMbrsqa/2wK9u9bgG6JDzkACmju30A== References: <4915F014FDD99049A9C3A8C1B832004F0277F329@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F027F586E@IMCSRV2.MITRE.ORG> <4915F014FDD99049A9C3A8C1B832004F02DB3EFD@IMCSRV2.MITRE.ORG> From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Jul 2008 05:15:20.0419 (UTC) FILETIME=[EE3F5330:01C8F070] X-Mailman-Approved-At: Mon, 28 Jul 2008 00:59:15 -0700 Cc: mib2rdml@ietf.org Subject: [Netconf] Expressing SNMP SMI Datatypes in XML Schema Definition Language -03 draft submitted X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076642729==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0076642729== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F070.BAA7AC6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have submitted an updated version (-03) of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", via the Internet-Drafts submission tool, but it will likely not get processed until following IETF-72. =20 In the meantime, interested parties can download a copy from: http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi-datatypes-in-x sd-03.txt =20 The0 The -03 version has some minor fix-ups (documented in the change log) and is being submitted now because the -02 version (which was posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) technical problem with the tool (apparently). =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 [I've included a couple of the NETCONF-related lists as bcc: addressees on this, since several recent threads on those lists have mentioned the XSDMI work. Further discussion about this draft, however, should be on the OPSAWG list.] =20 Cheers, BobN =20 From: Natale, Bob=20 Sent: Monday, July 14, 2008 7:17 PM To: opsawg@ietf.org Cc: mib2rdml@ietf.org Subject: Expressing SNMP SMI Datatypes in XML Schema Definition Language -02 draft submitted =20 Hi, =20 I have submitted an updated version of "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via the Internet-Drafts submission tool ahead of today's deadline, but had to do it via a "manual entry" due to administrative complications (once again!), which imposes some delays in the formal announcement process. =20 Pending formal publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-opsawg-smi-datatypes -in-xsd-02.txt. If that presents any problems for you, please let me know and I will forward you a copy directly. =20 This draft includes changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups noted in the Change Log section. =20 I hope that this version may be ready for WG last call. I will not be in Dublin, however - but will try to participate remotely if possible if this topic is discussed in the OPSAWG session there. =20 If anything is a hang-up, I suspect it will be in the XML registration section ("IANA Considerations"). =20 Please let me know your observations, etc. =20 Cheers, BobN =20 ------_=_NextPart_001_01C8F070.BAA7AC6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have submitted an updated version (-03) of = “Expressing SNMP SMI Datatypes in XML Schema Definition Language”, via the = Internet-Drafts submission tool, but it will likely not get processed until following = IETF-72.

 

In the meantime, interested parties can download a copy = from:

http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi= -datatypes-in-xsd-03.txt

 

The -03 version has some minor fix-ups (documented in the = change log) and is being submitted now because the -02 version (which was = posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) = technical problem with the tool (apparently).

 

I hope that this version may be ready for WG last = call.  I will not be in Dublin, however – but will try to participate = remotely if possible if this topic is discussed in the OPSAWG session = there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA = Considerations”).

 

Please let me know your observations, = etc.

 

[I’ve included a couple of the NETCONF-related lists = as bcc: addressees on this, since several recent threads on those lists = have mentioned the XSDMI work.  Further discussion about this draft, = however, should be on the OPSAWG list.]

 

Cheers,

BobN

Hi,

 

I have submitted an updated version (-03) of = “Expressing SNMP SMI Datatypes in XML Schema Definition Language”, via the = Internet-Drafts submission tool, but it will likely not get processed until following = IETF-72.

 

In the meantime, interested parties can download a copy = from:

http://home.comcast.net/~bobnatale/draft-ietf-opsawg-smi= -datatypes-in-xsd-03.txt

 

The -03 version has some minor fix-ups (documented in the = change log) and is being submitted now because the -02 version (which was = posted ahead of the IETF-72 cut-off time) got dropped as a result of an (on-going) = technical problem with the tool (apparently).

 

I hope that this version may be ready for WG last = call.  I will not be in Dublin, however – but will try to participate = remotely if possible if this topic is discussed in the OPSAWG session = there.

 

If anything is a hang-up, I suspect it will be in the XML registration section (“IANA = Considerations”).

 

Please let me know your observations, = etc.

 

[I’ve included a couple of the NETCONF-related lists = as bcc: addressees on this, since several recent threads on those lists = have mentioned the XSDMI work.  Further discussion about this draft, = however, should be on the OPSAWG list.]

 

Cheers,

BobN

 

From: Natale, Bob
Sent: Monday, July 14, 2008 7:17 PM
To: opsawg@ietf.org
Cc: mib2rdml@ietf.org
Subject: Expressing SNMP SMI Datatypes in XML Schema Definition = Language -02 draft submitted

 

Hi,=

 

I have submitted = an updated version of "Expressing SNMP SMI Datatypes in XML Schema = Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via = the Internet-Drafts submission tool ahead of today’s deadline, but had = to do it via a "manual entry" due to administrative complications = (once again!), which imposes some delays in the formal announcement = process.

 =

Pending formal = publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-= opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, = please let me know and I will forward you a copy = directly.

 

This draft includes = changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups = noted in the Change Log section.

 

I hope that this = version may be ready for WG last call.  I will not be in Dublin, however = – but will try to participate remotely if possible if this topic is discussed = in the OPSAWG session there.

 =

If anything is a = hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 

From: Natale, Bob
Sent: Monday, July 14, 2008 7:17 PM
To: opsawg@ietf.org
Cc: mib2rdml@ietf.org
Subject: Expressing SNMP SMI Datatypes in XML Schema Definition = Language -02 draft submitted

 

Hi,=

 

I have submitted = an updated version of "Expressing SNMP SMI Datatypes in XML Schema = Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-02.txt, via = the Internet-Drafts submission tool ahead of today’s deadline, but had = to do it via a "manual entry" due to administrative complications = (once again!), which imposes some delays in the formal announcement = process.

 =

Pending formal = publication, you can get a copy from the "staging" area at: http://www.ietf.org/proceedings/staging/draft-ietf-= opsawg-smi-datatypes-in-xsd-02.txt.  If that presents any problems for you, = please let me know and I will forward you a copy = directly.

 

This draft includes = changes made for comments on the -01 version received from Mark Ellison, Juergen Schoenwaelder, and David Harrington, and some other fix-ups = noted in the Change Log section.

 

I hope that this = version may be ready for WG last call.  I will not be in Dublin, however = – but will try to participate remotely if possible if this topic is discussed = in the OPSAWG session there.

 =

If anything is a = hang-up, I suspect it will be in the XML registration section (“IANA Considerations”).

 =

Please let me know your observations, etc.=

 

Cheers,=

BobN=

 =

------_=_NextPart_001_01C8F070.BAA7AC6E-- --===============0076642729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0076642729==-- s=3DMsoNormal style=3D'margin-left:.5in'> =

Please let me know your observations, etc.=

 

Cheers,=

BobN=

 =

------_=_NextPart_001_01C8F070.BAA7AC6E-- --===============0076642729== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0076642729==-- From netconf-bounces@ietf.org Mon Jul 28 15:28:18 2008 Return-Path: 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 25FCE3A6B1E; Mon, 28 Jul 2008 15:28:18 -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 BD0043A65A6 for ; Mon, 28 Jul 2008 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wGCyvC6ttFru for ; Mon, 28 Jul 2008 15:28:15 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 9EF823A6B1E for ; Mon, 28 Jul 2008 15:28:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 28 Jul 2008 15:28:25 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 15:27:45 -0700 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt thread-index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEA== References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> From: "Kent Watsen" To: "Sharon Chisholm" , X-OriginalArrivalTime: 28 Jul 2008 22:27:46.0143 (UTC) FILETIME=[28C6AEF0:01C8F101] Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org We haven't been able to find a reason to notify an app when a candidate datastore is modified - we only send out notifications for running and startup datastores. Of course, our notifications indicate which datastore was modified and so an app can filter the notification-stream to receive just the config-change events for the datastore(s) of interest. So, if the WG supports notifications for candidate datastores, apps can still filter them out. Regarding missing a configuration change event due to throttling - why does this matter? That is, are you supporting an auditing use-case whereby each event must be captured? - what happens if the device has purged the log before your app had a chance to re-fetch it? For us, simply kFrom netconf-bounces@ietf.org Mon Jul 28 15:28:18 2008 Return-Path: X-Original-To: netconf-archive@lists.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 25FCE3A6B1E; Mon, 28 Jul 2008 15:28:18 -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 BD0043A65A6 for ; Mon, 28 Jul 2008 15:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wGCyvC6ttFru for ; Mon, 28 Jul 2008 15:28:15 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with ESMTP id 9EF823A6B1E for ; Mon, 28 Jul 2008 15:28:15 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP; Mon, 28 Jul 2008 15:28:25 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jul 2008 15:27:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 15:27:45 -0700 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt thread-index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEA== References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> From: "Kent Watsen" To: "Sharon Chisholm" , X-OriginalArrivalTime: 28 Jul 2008 22:27:46.0143 (UTC) FILETIME=[28C6AEF0:01C8F101] Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org We haven't been able to find a reason to notify an app when a candidate datastore is modified - we only send out notifications for running and startup datastores. Of course, our notifications indicate which datastore was modified and so an app can filter the notification-stream to receive just the config-change events for the datastore(s) of interest. So, if the WG supports notifications for candidate datastores, apps can still filter them out. Regarding missing a configuration change event due to throttling - why does this matter? That is, are you supporting an auditing use-case whereby each event must be captured? - what happens if the device has purged the log before your app had a chance to re-fetch it? For us, sinowing that the configuration changed is what is most important - we plan to use fingerprints to track config-changes... BTW, note that some devices may support more than one candidate datastore and hence the notification would need to indicate the specific one (not just a const datastore-identifier like "candidate") Thanks, Kent > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Sharon Chisholm > Sent: Friday, July 25, 2008 9:28 AM > To: netconf@ietf.org > Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > I don't know if I'm suppose to use up a lot of bandwidth on the mailing > list to discuss things that are not yet part of the charter, but I > wanted to make a make a few comments about Data Change Notifications > (configuration changes) prior to the meeting. > > It needs to be clarified that configuration change notifications get > sent out for changes to the running configuration. This potentially > means that a bunch of edit-config operations are applied on a candidate > configuration to create this change. I suspect this means we need to > send multiple change events. I had based the description originally on > an implementation that only edited running configuration so I missed > this. > > An open issue is how to ensure that you didn't miss a configuration > change event due to throttling. The traditional use of sequence numbers > to aid detection of this doesn't work with filtering. Assigning a > version number to the entire configuration might be a more effective > method. This is easy with a centralized configuration store, but if the > configuration is distributed throughout the network element, I don't > know how hard this is. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, July 07, 2008 5:09 PM > To: netconf@ietf.org > Subject: [Netconf] FW: I-D > Action:draft-chisholm-netconf-not-content-00.txt > > Hi > > The following draft defines standard content for NETCONF Notifications, > with an aim to support full-lifecycle configuration management. This > work was deferred from the original NETCONF Notification protocol work > because of the separation of protocol and content and was brought up at > the mike (by someone other then the authors) at the last IETF meeting as > a gap in our NETCONF solution. > > We would like to discuss this work at the upcoming meeting in Dublin. > > Sharon > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 5:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NETCONF Notification Content > Author(s) : S. Chisholm, et al. > Filename : draft-chisholm-netconf-not-content-00.txt > Pages : 29 > Date : 2008-07-07 > > The NETCONF Event Notifications standard specifies the mechanism by > which NETCONF clients can subscribe to and receive event notifications. > However, with the exception of a timestamp, no standard Notification > content was defined. This memo defines a set of information that should > be included in all NETCONF notifications, information that should be > included based on class of notification and also defines a set of > specific notifications to support specific management functions, such as > configuration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 > 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ________________________________________mply knowing that the configuration changed is what is most important - we plan to use fingerprints to track config-changes... BTW, note that some devices may support more than one candidate datastore and hence the notification would need to indicate the specific one (not just a const datastore-identifier like "candidate") Thanks, Kent > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Sharon Chisholm > Sent: Friday, July 25, 2008 9:28 AM > To: netconf@ietf.org > Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > I don't know if I'm suppose to use up a lot of bandwidth on the mailing > list to discuss things that are not yet part of the charter, but I > wanted to make a make a few comments about Data Change Notifications > (configuration changes) prior to the meeting. > > It needs to be clarified that configuration change notifications get > sent out for changes to the running configuration. This potentially > means that a bunch of edit-config operations are applied on a candidate > configuration to create this change. I suspect this means we need to > send multiple change events. I had based the description originally on > an implementation that only edited running configuration so I missed > this. > > An open issue is how to ensure that you didn't miss a configuration > change event due to throttling. The traditional use of sequence numbers > to aid detection of this doesn't work with filtering. Assigning a > version number to the entire configuration might be a more effective > method. This is easy with a centralized configuration store, but if the > configuration is distributed throughout the network element, I don't > know how hard this is. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, July 07, 2008 5:09 PM > To: netconf@ietf.org > Subject: [Netconf] FW: I-D > Action:draft-chisholm-netconf-not-content-00.txt > > Hi > > The following draft defines standard content for NETCONF Notifications, > with an aim to support full-lifecycle configuration management. This > work was deferred from the original NETCONF Notification protocol work > because of the separation of protocol and content and was brought up at > the mike (by someone other then the authors) at the last IETF meeting as > a gap in our NETCONF solution. > > We would like to discuss this work at the upcoming meeting in Dublin. > > Sharon > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 5:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NETCONF Notification Content > Author(s) : S. Chisholm, et al. > Filename : draft-chisholm-netconf-not-content-00.txt > Pages : 29 > Date : 2008-07-07 > > The NETCONF Event Notifications standard specifies the mechanism by > which NETCONF clients can subscribe to and receive event notifications. > However, with the exception of a timestamp, no standard Notification > content was defined. This memo defines a set of information that should > be included in all NETCONF notifications, information that should be > included based on class of notification and also defines a set of > specific notifications to support specific management functions, such as > configuration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 > 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _________________________________________ > 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 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 From netconf-bounces@ietf.org Tue Jul 29 08:10:30 2008 Return-Path: X-Original-To: netconf-archive@lists.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 8237328C1C6; Tue, 29 Jul 2008 08:10:30 -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 9DCC03A6969 for ; Tue, 29 Jul 2008 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xxwg0xy6w1yp for ; Tue, 29 Jul 2008 08:10:27 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 60C5C3A68E8 for ; Tue, 29 Jul 2008 08:10:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m6TF8YO13833; Tue, 29 Jul 2008 15:08:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:10:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEAAjfDbg References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Kent Watsen" , Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The use case around throttling is that a configuration change has occurred but due to NE overload the configuration change notification gets dropped on the floor at some point, potentially before reaching the NETCONF server. If you are running a configuration application that replicates the NE's configuration for scalability or some other reason, you will now have a stale copy of the configuration, but may not know it. Sharon -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net] Sent: Monday, July 28, 2008 6:28 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: RE: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt We haven't been able to find a reason to notify an app when a candidate datastore is modified - we only send out notifications for running and startup datastores. Of course, our notifications indicate which datastore was modified and so an app can filter the notification-stream to receive just the config-change events for the datastore(s) of interest. So, if the WG supports notifications for candidate datastores, apps can still filter them ouFrom netconf-bounces@ietf.org Tue Jul 29 08:10:30 2008 Return-Path: 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 8237328C1C6; Tue, 29 Jul 2008 08:10:30 -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 9DCC03A6969 for ; Tue, 29 Jul 2008 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xxwg0xy6w1yp for ; Tue, 29 Jul 2008 08:10:27 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 60C5C3A68E8 for ; Tue, 29 Jul 2008 08:10:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m6TF8YO13833; Tue, 29 Jul 2008 15:08:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:10:28 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt Thread-Index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEAAjfDbg References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: "Kent Watsen" , Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi The use case around throttling is that a configuration change has occurred but due to NE overload the configuration change notification gets dropped on the floor at some point, potentially before reaching the NETCONF server. If you are running a configuration application that replicates the NE's configuration for scalability or some other reason, you will now have a stale copy of the configuration, but may not know it. Sharon -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net] Sent: Monday, July 28, 2008 6:28 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: RE: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt We haven't been able to find a reason to notify an app when a candidate datastore is modified - we only send out notifications for running and startup datastores. Of course, our notifications indicate which datastore was modified and so an app can filter the notification-stream to receive just the config-change events for the datastore(s) of interest. So, if the WG supports notifications for candidate datastores, apps can still filter them out. Ret. Regarding missing a configuration change event due to throttling - why does this matter? That is, are you supporting an auditing use-case whereby each event must be captured? - what happens if the device has purged the log before your app had a chance to re-fetch it? For us, simply knowing that the configuration changed is what is most important - we plan to use fingerprints to track config-changes... BTW, note that some devices may support more than one candidate datastore and hence the notification would need to indicate the specific one (not just a const datastore-identifier like "candidate") Thanks, Kent > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Sharon Chisholm > Sent: Friday, July 25, 2008 9:28 AM > To: netconf@ietf.org > Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > I don't know if I'm suppose to use up a lot of bandwidth on the mailing > list to discuss things that are not yet part of the charter, but I > wanted to make a make a few comments about Data Change Notifications > (configuration changes) prior to the meeting. > > It needs to be clarified that configuration change notifications get > sent out for changes to the running configuration. This potentially > means that a bunch of edit-config operations are applied on a candidate > configuration to create this change. I suspect this means we need to > send multiple change events. I had based the description originally on > an implementation that only edited running configuration so I missed > this. > > An open issue is how to ensure that you didn't miss a configuration > change event due to throttling. The traditional use of sequence numbers > to aid detection of this doesn't work with filtering. Assigning a > version number to the entire configuration might be a more effective > method. This is easy with a centralized configuration store, but if the > configuration is distributed throughout the network element, I don't > know how hard this is. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, July 07, 2008 5:09 PM > To: netconf@ietf.org > Subject: [Netconf] FW: I-D > Action:draft-chisholm-netconf-not-content-00.txt > > Hi > > The following draft defines standard content for NETCONF Notifications, > with an aim to support full-lifecycle configuration management. This > work was deferred from the original NETCONF Notification protocol work > because of the separation of protocol and content and was brought up at > the mike (by someone other then the authors) at the last IETF meeting as > a gap in our NETCONF solution. > > We would like to discuss this work at the upcoming meeting in Dublin. > > Sharon > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 5:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NETCONF Notification Content > Author(s) : S. Chisholm, et al. > Filename : draft-chisholm-netconf-not-content-00.txt > Pages : 29 > Date : 2008-07-07 > > The NETCONF Event Notifications standard specifies the mechanism by > which NETCONF clients can subscribe to and receive event notifications. > However, with the exception of a timestamp, no standard Notification > content was defined. This memo defines a set of information that should > be included in all NETCONF notifications, information that should be > included based on class of notification and also defines a set of > specific notifications to support specific management functions, such as > configuration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-contegarding missing a configuration change event due to throttling - why does this matter? That is, are you supporting an auditing use-case whereby each event must be captured? - what happens if the device has purged the log before your app had a chance to re-fetch it? For us, simply knowing that the configuration changed is what is most important - we plan to use fingerprints to track config-changes... BTW, note that some devices may support more than one candidate datastore and hence the notification would need to indicate the specific one (not just a const datastore-identifier like "candidate") Thanks, Kent > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf > Of Sharon Chisholm > Sent: Friday, July 25, 2008 9:28 AM > To: netconf@ietf.org > Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > I don't know if I'm suppose to use up a lot of bandwidth on the mailing > list to discuss things that are not yet part of the charter, but I > wanted to make a make a few comments about Data Change Notifications > (configuration changes) prior to the meeting. > > It needs to be clarified that configuration change notifications get > sent out for changes to the running configuration. This potentially > means that a bunch of edit-config operations are applied on a candidate > configuration to create this change. I suspect this means we need to > send multiple change events. I had based the description originally on > an implementation that only edited running configuration so I missed > this. > > An open issue is how to ensure that you didn't miss a configuration > change event due to throttling. The traditional use of sequence numbers > to aid detection of this doesn't work with filtering. Assigning a > version number to the entire configuration might be a more effective > method. This is easy with a centralized configuration store, but if the > configuration is distributed throughout the network element, I don't > know how hard this is. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Monday, July 07, 2008 5:09 PM > To: netconf@ietf.org > Subject: [Netconf] FW: I-D > Action:draft-chisholm-netconf-not-content-00.txt > > Hi > > The following draft defines standard content for NETCONF Notifications, > with an aim to support full-lifecycle configuration management. This > work was deferred from the original NETCONF Notification protocol work > because of the separation of protocol and content and was brought up at > the mike (by someone other then the authors) at the last IETF meeting as > a gap in our NETCONF solution. > > We would like to discuss this work at the upcoming meeting in Dublin. > > Sharon > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Monday, July 07, 2008 5:00 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NETCONF Notification Content > Author(s) : S. Chisholm, et al. > Filename : draft-chisholm-netconf-not-content-00.txt > Pages : 29 > Date : 2008-07-07 > > The NETCONF Event Notifications standard specifies the mechanism by > which NETCONF clients can subscribe to and receive event notifications. > However, with the exception of a timestamp, no standard Notification > content was defined. This memo defines a set of information that should > be included in all NETCONF notifications, information that should be > included based on class of notification and also defines a set of > specific notifications to support specific management functions, such as > configuration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 >nt-0 > 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 From netconf-bounces@ietf.org Tue Jul 29 11:18:56 2008 Return-Path: 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 4C1EB3A6A5A; Tue, 29 Jul 2008 11:18:56 -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 BFA4A3A6916 for ; Tue, 29 Jul 2008 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6] 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 cVXqxxBoNtlb for ; Tue, 29 Jul 2008 11:18:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1A7E3A67EB for ; Tue, 29 Jul 2008 11:18:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A662C0042 for ; Tue, 29 Jul 2008 20:19:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2visug2gZT8q; Tue, 29 Jul 2008 20:19:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C0A2C002B; Tue, 29 Jul 2008 20:19:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 04B2B67AE9E; Tue, 29 Jul 2008 20:18:58 +0200 (CEST) Date: Tue, 29 Jul 2008 20:18:58 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080729181858.GA12104@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, the monitoring draft says: loginTime: Time (UTC) at which the session was established. Since the data type is xs:dateTime, I think the '(UTC)' part does not make sense and should be removed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 29 11:18:56 2008 Return-Path: X-Original-To: netconf-archive@lists.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 4C1EB3A6A5A; Tue, 29 Jul 2008 11:18:56 -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 BFA4A3A6916 for ; Tue, 29 Jul 2008 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6] 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 cVXqxxBoNtlb for ; Tue, 29 Jul 2008 11:18:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D1A7E3A67EB for ; Tue, 29 Jul 2008 11:18:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A662C0042 for ; Tue, 29 Jul 2008 20:19:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2visug2gZT8q; Tue, 29 Jul 2008 20:19:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C0A2C002B; Tue, 29 Jul 2008 20:19:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 04B2B67AE9E; Tue, 29 Jul 2008 20:18:58 +0200 (CEST) Date: Tue, 29 Jul 2008 20:18:58 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080729181858.GA12104@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, the monitoring draft says: loginTime: Time (UTC) at which the session was established. Since the data type is xs:dateTime, I think the '(UTC)' part does not make sense and should be removed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 29 11:58:35 2008 Return-Path: X-Original-To: netconf-archive@lists.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 67CD23A6B59; Tue, 29 Jul 2008 11:58:35 -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 F27913A6B59 for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 3mh36aatdlVA for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 6381C3A6B4B for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) Received: (qmail 41108 invoked from network); 29 Jul 2008 18:58:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2008 18:58:39 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F685D.2000107@netconfcentral.com> Date: Tue, 29 Jul 2008 11:58:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I supported this work at the last IETF. However, IMO, only a very limited scope would make sense before NETMOD is finished. The only notification content that would help ASAP: - EventClass typedef - ConfigChange (basic) - HardwareChange (basic) Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jul 29 11:58:35 2008 Return-Path: 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 67CD23A6B59; Tue, 29 Jul 2008 11:58:35 -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 F27913A6B59 for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 3mh36aatdlVA for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 6381C3A6B4B for ; Tue, 29 Jul 2008 11:58:34 -0700 (PDT) Received: (qmail 41108 invoked from network); 29 Jul 2008 18:58:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 29 Jul 2008 18:58:39 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <488F685D.2000107@netconfcentral.com> Date: Tue, 29 Jul 2008 11:58:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I supported this work at the last IETF. However, IMO, only a very limited scope would make sense before NETMOD is finished. The only notification content that would help ASAP: - EventClass typedef - ConfigChange (basic) - HardwareChange (basic) Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 05:33:42 2008 Return-Path: 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 011DC28C1C8; Wed, 30 Jul 2008 05:33:42 -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 CDF5628C2D5 for ; Wed, 30 Jul 2008 05:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Avr5STszaDoP for ; Wed, 30 Jul 2008 05:33:40 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DEBA728C1C8 for ; Wed, 30 Jul 2008 05:33:39 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UCXpV18706 for ; Wed, 30 Jul 2008 12:33:52 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 08:33:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AOB from yesterday's Meeting Thread-Index: AcjyQHwbLxKs3SVoTbCf7s2u57JZBQ== From: "Sharon Chisholm" To: Subject: [Netconf] AOB from yesterday's Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi We sort of rushed out of the meeting yesterday without getting to discussion of RFC4741 bis or whether there is other work the group should be doing. The only comment I would have made is that in theory with need to also look at updating a couple of the transport documents to support Notifications. It isn't urgent since I the change is fairly obvious, but technically the transport documents discuss mapping to and and the does not use these, so from a really pedantic point of view, we don't have a mapping. I don't expect in practice this will cause problems, but we should fix that at some point. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 05:33:42 2008 Return-Path: X-Original-To: netconf-archive@lists.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 011DC28C1C8; Wed, 30 Jul 2008 05:33:42 -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 CDF5628C2D5 for ; Wed, 30 Jul 2008 05:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Avr5STszaDoP for ; Wed, 30 Jul 2008 05:33:40 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id DEBA728C1C8 for ; Wed, 30 Jul 2008 05:33:39 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UCXpV18706 for ; Wed, 30 Jul 2008 12:33:52 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 08:33:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AOB from yesterday's Meeting Thread-Index: AcjyQHwbLxKs3SVoTbCf7s2u57JZBQ== From: "Sharon Chisholm" To: Subject: [Netconf] AOB from yesterday's Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi We sort of rushed out of the meeting yesterday without getting to discussion of RFC4741 bis or whether there is other work the group should be doing. The only comment I would have made is that in theory with need to also look at updating a couple of the transport documents to support Notifications. It isn't urgent since I the change is fairly obvious, but technically the transport documents discuss mapping to and and the does not use these, so from a really pedantic point of view, we don't have a mapping. I don't expect in practice this will cause problems, but we should fix that at some point. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 08:04:05 2008 Return-Path: X-Original-To: netconf-archive@lists.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 7281B3A6A13; Wed, 30 Jul 2008 08:04:05 -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 60D393A6A13 for ; Wed, 30 Jul 2008 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 alVeezwQamvc for ; Wed, 30 Jul 2008 08:04:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BFEAF3A68C7 for ; Wed, 30 Jul 2008 08:04:02 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UF4Eu26440; Wed, 30 Jul 2008 15:04:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 11:03:27 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> In-Reply-To: <20080729181858.GA12104@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] UTC in monitoring draft Thread-Index: Acjxp57PM6x8X0A3Tvy0yfjahmPDKwAmUDRw References: <20080729181858.GA12104@elstar.local> From: "Mark Scott" To: , Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I'm not sure it doesn't make sense but UTC handling is already defined in the xs:dateTime definition. So I will remove it. thx, mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, July 29, 2008 2:19 PM To: netconf@ietf.org Subject: [Netconf] UTC in monitoring draft Hi, the monitoring draft says: loginTime: Time (UTC) at which the session was established. Since the data type is xs:dateTime, I think the '(UTC)' part does not make sense and should be removed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 30 08:04:05 2008 Return-Path: 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 7281B3A6A13; Wed, 30 Jul 2008 08:04:05 -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 60D393A6A13 for ; Wed, 30 Jul 2008 08:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 alVeezwQamvc for ; Wed, 30 Jul 2008 08:04:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BFEAF3A68C7 for ; Wed, 30 Jul 2008 08:04:02 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UF4Eu26440; Wed, 30 Jul 2008 15:04:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 11:03:27 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> In-Reply-To: <20080729181858.GA12104@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] UTC in monitoring draft Thread-Index: Acjxp57PM6x8X0A3Tvy0yfjahmPDKwAmUDRw References: <20080729181858.GA12104@elstar.local> From: "Mark Scott" To: , Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I'm not sure it doesn't make sense but UTC handling is already defined in the xs:dateTime definition. So I will remove it. thx, mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Tuesday, July 29, 2008 2:19 PM To: netconf@ietf.org Subject: [Netconf] UTC in monitoring draft Hi, the monitoring draft says: loginTime: Time (UTC) at which the session was established. Since the data type is xs:dateTime, I think the '(UTC)' part does not make sense and should be removed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 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 From netconf-bounces@ietf.org Wed Jul 30 08:31:17 2008 Return-Path: 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 224BB3A6946; Wed, 30 Jul 2008 08:31:17 -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 39D523A68C7 for ; Wed, 30 Jul 2008 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6] 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 jWfXUdCbIyUy for ; Wed, 30 Jul 2008 08:31:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 537673A688B for ; Wed, 30 Jul 2008 08:31:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A0E5C0038; Wed, 30 Jul 2008 17:31:12 +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 C2xGILGJVWvW; Wed, 30 Jul 2008 17:31:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A179C0037; Wed, 30 Jul 2008 17:31:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6834467C6CC; Wed, 30 Jul 2008 17:31:04 +0200 (CEST) Date: Wed, 30 Jul 2008 17:31:04 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20080730153104.GB14483@elstar.local> Mail-Followup-To: Mark Scott , netconf@ietf.org References: <20080729181858.GA12104@elstar.local> <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 30, 2008 at 11:03:27AM -0400, Mark Scott wrote: > I'm not sure it doesn't make sense but UTC handling is already > defined in the xs:dateTime definition. Since xs:dateTime takes care of time zones, why do you want to restrict things to UTC? If you have a reason to restrict the timezone to UTC, you might want to spell it out since I could not imagine one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 08:31:17 2008 Return-Path: X-Original-To: netconf-archive@lists.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 224BB3A6946; Wed, 30 Jul 2008 08:31:17 -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 39D523A68C7 for ; Wed, 30 Jul 2008 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_28=0.6] 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 jWfXUdCbIyUy for ; Wed, 30 Jul 2008 08:31:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 537673A688B for ; Wed, 30 Jul 2008 08:31:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A0E5C0038; Wed, 30 Jul 2008 17:31:12 +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 C2xGILGJVWvW; Wed, 30 Jul 2008 17:31:05 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A179C0037; Wed, 30 Jul 2008 17:31:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6834467C6CC; Wed, 30 Jul 2008 17:31:04 +0200 (CEST) Date: Wed, 30 Jul 2008 17:31:04 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20080730153104.GB14483@elstar.local> Mail-Followup-To: Mark Scott , netconf@ietf.org References: <20080729181858.GA12104@elstar.local> <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Wed, Jul 30, 2008 at 11:03:27AM -0400, Mark Scott wrote: > I'm not sure it doesn't make sense but UTC handling is already > defined in the xs:dateTime definition. Since xs:dateTime takes care of time zones, why do you want to restrict things to UTC? If you have a reason to restrict the timezone to UTC, you might want to spell it out since I could not imagine one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 08:47:55 2008 Return-Path: X-Original-To: netconf-archive@lists.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 04A7228C30A; Wed, 30 Jul 2008 08:47:55 -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 B87E728C283 for ; Wed, 30 Jul 2008 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 QEmi-y5Bxp5d for ; Wed, 30 Jul 2008 08:47:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 0D29028C0E1 for ; Wed, 30 Jul 2008 08:47:48 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UFlwF13136; Wed, 30 Jul 2008 15:47:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 11:47:36 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB13379890@zcarhxm1.corp.nortel.com> In-Reply-To: <20080730153104.GB14483@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] UTC in monitoring draft Thread-Index: AcjyWVBd7850PG9rQq2to6BHHz185gAAGYDQ References: <20080729181858.GA12104@elstar.local> <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> <20080730153104.GB14483@elstar.local> From: "Mark Scott" To: Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sorry, I should have been clearer. I said I would remove the reference and the implied restriction. This still leaves implementors free to limit the time reported to UTC if they choose. This is consistent with our products. We report all management data in UTC (where supported) to facilitate correlation without the need for timezone conversion. We defer conversion to the presentation layer if/when needed. Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, July 30, 2008 11:31 AM To: Scott, Mark (CAR:2Y01) Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft On Wed, Jul 30, 2008 at 11:03:27AM -0400, Mark Scott wrote: > I'm not sure it doesn't make sense but UTC handling is already defined > in the xs:dateTime definition. Since xs:dateTime takes care of time zones, why do you want to restrict things to UTC? If you have a reason to restrict the timezone to UTC, you might want to spell it out since I could not imagine one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 08:47:55 2008 Return-Path: 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 04A7228C30A; Wed, 30 Jul 2008 08:47:55 -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 B87E728C283 for ; Wed, 30 Jul 2008 08:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_28=0.6, 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 QEmi-y5Bxp5d for ; Wed, 30 Jul 2008 08:47:50 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 0D29028C0E1 for ; Wed, 30 Jul 2008 08:47:48 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6UFlwF13136; Wed, 30 Jul 2008 15:47:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 11:47:36 -0400 Message-ID: <183DD1B052A11A40B76125E42F1CBAAB13379890@zcarhxm1.corp.nortel.com> In-Reply-To: <20080730153104.GB14483@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] UTC in monitoring draft Thread-Index: AcjyWVBd7850PG9rQq2to6BHHz185gAAGYDQ References: <20080729181858.GA12104@elstar.local> <183DD1B052A11A40B76125E42F1CBAAB133797B1@zcarhxm1.corp.nortel.com> <20080730153104.GB14483@elstar.local> From: "Mark Scott" To: Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sorry, I should have been clearer. I said I would remove the reference and the implied restriction. This still leaves implementors free to limit the time reported to UTC if they choose. This is consistent with our products. We report all management data in UTC (where supported) to facilitate correlation without the need for timezone conversion. We defer conversion to the presentation layer if/when needed. Mark -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, July 30, 2008 11:31 AM To: Scott, Mark (CAR:2Y01) Cc: netconf@ietf.org Subject: Re: [Netconf] UTC in monitoring draft On Wed, Jul 30, 2008 at 11:03:27AM -0400, Mark Scott wrote: > I'm not sure it doesn't make sense but UTC handling is already defined > in the xs:dateTime definition. Since xs:dateTime takes care of time zones, why do you want to restrict things to UTC? If you have a reason to restrict the timezone to UTC, you might want to spell it out since I could not imagine one. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 09:06:43 2008 Return-Path: X-Original-To: netconf-archive@lists.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 905CA3A68C7; Wed, 30 Jul 2008 09:06:43 -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 D35B53A68C7 for ; Wed, 30 Jul 2008 09:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 lqt6kCMwdIkk for ; Wed, 30 Jul 2008 09:06:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8006A3A695D for ; Wed, 30 Jul 2008 09:06:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6UG6rku009918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 18:06:53 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6UG6rfx002798; Wed, 30 Jul 2008 18:06:53 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:06:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 18:06:52 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] AOB from yesterday's Meeting Thread-Index: AcjyQHwbLxKs3SVoTbCf7s2u57JZBQAHDM0w References: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" X-OriginalArrivalTime: 30 Jul 2008 16:06:53.0409 (UTC) FILETIME=[484FB510:01C8F25E] Cc: netconf@ietf.org Subject: Re: [Netconf] AOB from yesterday's Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, we did not have sufficient time for AOB discussion. There is one additional slide at the end of the WG status slides summarizing -bis-related issues. We should bring this again to discussion when I send the WG session summary to the NETCONF maillist for confirmation. As you say below the -bis draft is not urgent and might become part of the rechartering discussion. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Sharon Chisholm > Sent: Wednesday, July 30, 2008 2:34 PM > To: netconf@ietf.org > Subject: [Netconf] AOB from yesterday's Meeting > > Hi > > We sort of rushed out of the meeting yesterday without getting to > discussion of RFC4741 bis or whether there is other work the gFrom netconf-bounces@ietf.org Wed Jul 30 09:06:43 2008 Return-Path: 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 905CA3A68C7; Wed, 30 Jul 2008 09:06:43 -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 D35B53A68C7 for ; Wed, 30 Jul 2008 09:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 lqt6kCMwdIkk for ; Wed, 30 Jul 2008 09:06:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8006A3A695D for ; Wed, 30 Jul 2008 09:06:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m6UG6rku009918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 18:06:53 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6UG6rfx002798; Wed, 30 Jul 2008 18:06:53 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 18:06:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 18:06:52 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] AOB from yesterday's Meeting Thread-Index: AcjyQHwbLxKs3SVoTbCf7s2u57JZBQAHDM0w References: <713043CE8B8E1348AF3C546DBE02C1B415AD190C@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" X-OriginalArrivalTime: 30 Jul 2008 16:06:53.0409 (UTC) FILETIME=[484FB510:01C8F25E] Cc: netconf@ietf.org Subject: Re: [Netconf] AOB from yesterday's Meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, we did not have sufficient time for AOB discussion. There is one additional slide at the end of the WG status slides summarizing -bis-related issues. We should bring this again to discussion when I send the WG session summary to the NETCONF maillist for confirmation. As you say below the -bis draft is not urgent and might become part of the rechartering discussion. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of ext Sharon Chisholm > Sent: Wednesday, July 30, 2008 2:34 PM > To: netconf@ietf.org > Subject: [Netconf] AOB from yesterday's Meeting > > Hi > > We sort of rushed out of the meeting yesterday without getting to > discussion of RFC4741 bis or whether there is other work the group >roup > should be doing. The only comment I would have made is that in theory > with need to also look at updating a couple of the transport documents > to support Notifications. It isn't urgent since I the change is fairly > obvious, but technically the transport documents discuss mapping to > and and the does not use > these, so from > a really pedantic point of view, we don't have a mapping. I > don't expect > in practice this will cause problems, but we should fix that at some > point. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 should be doing. The only comment I would have made is that in theory > with need to also look at updating a couple of the transport documents > to support Notifications. It isn't urgent since I the change is fairly > obvious, but technically the transport documents discuss mapping to > and and the does not use > these, so from > a really pedantic point of view, we don't have a mapping. I > don't expect > in practice this will cause problems, but we should fix that at some > point. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > 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 From netconf-bounces@ietf.org Wed Jul 30 13:42:24 2008 Return-Path: X-Original-To: netconf-archive@lists.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 DC5CC3A689D; Wed, 30 Jul 2008 13:42:24 -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 0D96B3A689D for ; Wed, 30 Jul 2008 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 aZPWEh+9IhxH for ; Wed, 30 Jul 2008 13:42:22 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 116D73A685E for ; Wed, 30 Jul 2008 13:42:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 13:42:24 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:24 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:41:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enhancement proposal for NetConf's thread-index: AcjyhKKC9Yo1EqpWQ3CWhBf+p3paVg== From: "Kent Watsen" To: X-OriginalArrivalTime: 30 Jul 2008 20:41:23.0645 (UTC) FILETIME=[A15646D0:01C8F284] Subject: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Section 7.5 (i.e. "") of the NetConf spec reads: A lock MUST not be granted if either of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. The 2nd bullet-point can lead to an app wedging itself when its own editing session drops unexpectedly, prior to it executing , and thus leaving contents in the candidate datastore. This is a problem because the app can't be sure that the contents in the candidate datastore are from its previous session or some other user, which results in it going into an exception-handler (potentially involving end-user approval) It would be much cleaner if NetConf could provide an auto-rollback guarantee to handling dropped sessions. For instance, something like: ... At least then an app can beFrom netconf-bounces@ietf.org Wed Jul 30 13:42:24 2008 Return-Path: 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 DC5CC3A689D; Wed, 30 Jul 2008 13:42:24 -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 0D96B3A689D for ; Wed, 30 Jul 2008 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 aZPWEh+9IhxH for ; Wed, 30 Jul 2008 13:42:22 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 116D73A685E for ; Wed, 30 Jul 2008 13:42:22 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 13:42:24 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:24 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:24 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:41:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:41:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Enhancement proposal for NetConf's thread-index: AcjyhKKC9Yo1EqpWQ3CWhBf+p3paVg== From: "Kent Watsen" To: X-OriginalArrivalTime: 30 Jul 2008 20:41:23.0645 (UTC) FILETIME=[A15646D0:01C8F284] Subject: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Section 7.5 (i.e. "") of the NetConf spec reads: A lock MUST not be granted if either of the following conditions is true: * A lock is already held by any NETCONF session or another entity. * The target configuration is , it has already been modified, and these changes have not been committed or rolled back. The 2nd bullet-point can lead to an app wedging itself when its own editing session drops unexpectedly, prior to it executing , and thus leaving contents in the candidate datastore. This is a problem because the app can't be sure that the contents in the candidate datastore are from its previous session or some other user, which results in it going into an exception-handler (potentially involving end-user approval) It would be much cleaner if NetConf could provide an auto-rollback guarantee to handling dropped sessions. For instance, something like: ... At least then an app can be sure sure that the contents in the candidate datastore are not leftover from its own editing session and hence warranting the end-user approval to What do you think? Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf that the contents in the candidate datastore are not leftover from its own editing session and hence warranting the end-user approval to What do you think? Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 13:54:14 2008 Return-Path: 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 A64673A6905; Wed, 30 Jul 2008 13:54:14 -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 34B113A6905 for ; Wed, 30 Jul 2008 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 vIxg-0Hgyf6s for ; Wed, 30 Jul 2008 13:54:10 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C54DC3A6876 for ; Wed, 30 Jul 2008 13:54:09 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 13:54:24 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:22 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:54:21 -0700 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt thread-index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEAAjfDbgAD5J3lA= References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> From: "Kent Watsen" To: "Sharon Chisholm" , X-OriginalArrivalTime: 30 Jul 2008 20:54:22.0360 (UTC) FILETIME=[717CC180:01C8F286] Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sorry, I meant, why does it matter to know the sequence-number of the missed logs? - is your intent for the application to use the sequence-number to re-fetch the log that was throttled? If not, then maybe a fingerprint would be better? Thanks, Kent > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Tuesday, July 29, 2008 11:10 AM > To: Kent Watsen; netconf@ietf.org > Subject: RE: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > The use case around throttling is that a configuration change has > occurred but due From netconf-bounces@ietf.org Wed Jul 30 13:54:14 2008 Return-Path: X-Original-To: netconf-archive@lists.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 A64673A6905; Wed, 30 Jul 2008 13:54:14 -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 34B113A6905 for ; Wed, 30 Jul 2008 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 vIxg-0Hgyf6s for ; Wed, 30 Jul 2008 13:54:10 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C54DC3A6876 for ; Wed, 30 Jul 2008 13:54:09 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 13:54:24 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:23 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:22 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 13:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 13:54:21 -0700 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt thread-index: AcjgdRnapLxzL17RRpWdYodYavx2bgAACaswA3jZ4LAAqYxEEAAjfDbgAD5J3lA= References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B415A81181@zcarhxm2.corp.nortel.com> From: "Kent Watsen" To: "Sharon Chisholm" , X-OriginalArrivalTime: 30 Jul 2008 20:54:22.0360 (UTC) FILETIME=[717CC180:01C8F286] Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sorry, I meant, why does it matter to know the sequence-number of the missed logs? - is your intent for the application to use the sequence-number to re-fetch the log that was throttled? If not, then maybe a fingerprint would be better? Thanks, Kent > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Tuesday, July 29, 2008 11:10 AM > To: Kent Watsen; netconf@ietf.org > Subject: RE: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content- > 00.txt > > Hi > > The use case around throttling is that a configuration change has > occurred buto NE overload the configuration change notification > gets dropped on the floor at some point, potentially before reaching the > NETCONF server. If you are running a configuration application that > replicates the NE's configuration for scalability or some other reason, > you will now have a stale copy of the configuration, but may not know > it. > > Sharon > > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Monday, July 28, 2008 6:28 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: RE: [Netconf] FW: > I-DAction:draft-chisholm-netconf-not-content-00.txt > > > We haven't been able to find a reason to notify an app when a candidate > datastore is modified - we only send out notifications for running and > startup datastores. Of course, our notifications indicate which > datastore was modified and so an app can filter the notification-stream > to receive just the config-change events for the datastore(s) of > interest. So, if the WG supports notifications for candidate > datastores, apps can still filter them out. > > Regarding missing a configuration change event due to throttling - why > does this matter? That is, are you supporting an auditing use-case > whereby each event must be captured? - what happens if the device has > purged the log before your app had a chance to re-fetch it? For us, > simply knowing that the configuration changed is what is most important > - we plan to use fingerprints to track config-changes... > > BTW, note that some devices may support more than one candidate > datastore and hence the notification would need to indicate the specific > one (not just a const datastore-identifier like "candidate") > > Thanks, > Kent > > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf > > Of Sharon Chisholm > > Sent: Friday, July 25, 2008 9:28 AM > > To: netconf@ietf.org > > Subject: Re: [Netconf] FW: > I-DAction:draft-chisholm-netconf-not-content- > > 00.txt > > > > Hi > > > > I don't know if I'm suppose to use up a lot of bandwidth on the > mailing > > list to discuss things that are not yet part of the charter, but I > > wanted to make a make a few comments about Data Change Notifications > > (configuration changes) prior to the meeting. > > > > It needs to be clarified that configuration change notifications get > > sent out for changes to the running configuration. This potentially > > means that a bunch of edit-config operations are applied on a > candidate > > configuration to create this change. I suspect this means we need to > > send multiple change events. I had based the description originally on > > > an implementation that only edited running configuration so I missed > > this. > > > > An open issue is how to ensure that you didn't miss a configuration > > change event due to throttling. The traditional use of sequence > numbers > > to aid detection of this doesn't work with filtering. Assigning a > > version number to the entire configuration might be a more effective > > method. This is easy with a centralized configuration store, but if > the > > configuration is distributed throughout the network element, I don't > > know how hard this is. > > > > Sharon > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Chisholm, Sharon (CAR:ZZ00) > > Sent: Monday, July 07, 2008 5:09 PM > > To: netconf@ietf.org > > Subject: [Netconf] FW: I-D > > Action:draft-chisholm-netconf-not-content-00.txt > > > > Hi > > > > The following draft defines standard content for NETCONF > Notifications, > > with an aim to support full-lifecycle configuration management. This > > work was deferred from the original NETCONF Notification protocol work > > > because of the separation of protocol and content and was brought up > at > > the mike (by someone other then the authors) at the last IETF meeting > as > > a gap in our NETCONF solution. > > > > We would like to discuss this work at the upcoming meeting in Dublin. > > > > Sharon > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Monday, July 07, 2008 5:00 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : NETCONF Notification Content > > Author(s) : S. Chisholm, et al. > > Filename : draft-chisholm-netconf-not-content-00.txt > > Pages : 29 > > Date : 2008-07-07 > > > > The NETCONF Event Notifications standard specifies the mechanism by > > which NETCONF clients can subscribe to and receive event > notifications. > > However, with the exception of a timestamp, no standard Notification > > content was defined. This memo defines a set of information that > should > > be included in all NETCONF notifications, information that should be > > included based on class of notification and also defines a set of > > specific notifications to support specific management functions, such > as > > configuration. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 > > 0.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > 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 t due to NE overload the configuration change notification > gets dropped on the floor at some point, potentially before reaching the > NETCONF server. If you are running a configuration application that > replicates the NE's configuration for scalability or some other reason, > you will now have a stale copy of the configuration, but may not know > it. > > Sharon > > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Monday, July 28, 2008 6:28 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: RE: [Netconf] FW: > I-DAction:draft-chisholm-netconf-not-content-00.txt > > > We haven't been able to find a reason to notify an app when a candidate > datastore is modified - we only send out notifications for running and > startup datastores. Of course, our notifications indicate which > datastore was modified and so an app can filter the notification-stream > to receive just the config-change events for the datastore(s) of > interest. So, if the WG supports notifications for candidate > datastores, apps can still filter them out. > > Regarding missing a configuration change event due to throttling - why > does this matter? That is, are you supporting an auditing use-case > whereby each event must be captured? - what happens if the device has > purged the log before your app had a chance to re-fetch it? For us, > simply knowing that the configuration changed is what is most important > - we plan to use fingerprints to track config-changes... > > BTW, note that some devices may support more than one candidate > datastore and hence the notification would need to indicate the specific > one (not just a const datastore-identifier like "candidate") > > Thanks, > Kent > > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf > > Of Sharon Chisholm > > Sent: Friday, July 25, 2008 9:28 AM > > To: netconf@ietf.org > > Subject: Re: [Netconf] FW: > I-DAction:draft-chisholm-netconf-not-content- > > 00.txt > > > > Hi > > > > I don't know if I'm suppose to use up a lot of bandwidth on the > mailing > > list to discuss things that are not yet part of the charter, but I > > wanted to make a make a few comments about Data Change Notifications > > (configuration changes) prior to the meeting. > > > > It needs to be clarified that configuration change notifications get > > sent out for changes to the running configuration. This potentially > > means that a bunch of edit-config operations are applied on a > candidate > > configuration to create this change. I suspect this means we need to > > send multiple change events. I had based the description originally on > > > an implementation that only edited running configuration so I missed > > this. > > > > An open issue is how to ensure that you didn't miss a configuration > > change event due to throttling. The traditional use of sequence > numbers > > to aid detection of this doesn't work with filtering. Assigning a > > version number to the entire configuration might be a more effective > > method. This is easy with a centralized configuration store, but if > the > > configuration is distributed throughout the network element, I don't > > know how hard this is. > > > > Sharon > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > > Behalf Of Chisholm, Sharon (CAR:ZZ00) > > Sent: Monday, July 07, 2008 5:09 PM > > To: netconf@ietf.org > > Subject: [Netconf] FW: I-D > > Action:draft-chisholm-netconf-not-content-00.txt > > > > Hi > > > > The following draft defines standard content for NETCONF > Notifications, > > with an aim to support full-lifecycle configuration management. This > > work was deferred from the original NETCONF Notification protocol work > > > because of the separation of protocol and content and was brought up > at > > the mike (by someone other then the authors) at the last IETF meeting > as > > a gap in our NETCONF solution. > > > > We would like to discuss this work at the upcoming meeting in Dublin. > > > > Sharon > > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Monday, July 07, 2008 5:00 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-chisholm-netconf-not-content-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : NETCONF Notification Content > > Author(s) : S. Chisholm, et al. > > Filename : draft-chisholm-netconf-not-content-00.txt > > Pages : 29 > > Date : 2008-07-07 > > > > The NETCONF Event Notifications standard specifies the mechanism by > > which NETCONF clients can subscribe to and receive event > notifications. > > However, with the exception of a timestamp, no standard Notification > > content was defined. This memo defines a set of information that > should > > be included in all NETCONF notifications, information that should be > > included based on class of notification and also defines a set of > > specific notifications to support specific management functions, such > as > > configuration. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-chisholm-netconf-not-content-0 > > 0.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > 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 From netconf-bounces@ietf.org Wed Jul 30 14:17:19 2008 Return-Path: X-Original-To: netconf-archive@lists.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 5DE193A6893; Wed, 30 Jul 2008 14:17:19 -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 5B37C3A6893 for ; Wed, 30 Jul 2008 14:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] 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 f5AT+Nojr7dA for ; Wed, 30 Jul 2008 14:17:17 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 6FA8E3A6840 for ; Wed, 30 Jul 2008 14:17:17 -0700 (PDT) Received: (qmail 50631 invoked from network); 30 Jul 2008 21:17:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 21:17:30 -0000 X-YMail-OSG: PPYRtzcVM1mctDNOgB6ArIrArTa1CXYAC1A_EUF_Bin6vWXp3eLHBXgVcbzDVHiUb6_qX.pNVnIk4x.Z9E70_GgD8_A3Yvu_6wemnLNq6A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890DA68.8040201@netconfcentral.com> Date: Wed, 30 Jul 2008 14:17:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: > Section 7.5 (i.e. "") of the NetConf spec reads: > > A lock MUST not be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > > The 2nd bullet-point can lead to an app wedging itself when its own > editing session drops unexpectedly, prior to it executing , and > thus leaving contents in the candidate datastore. > > This is a problem because the app can't be sure that the contents in the > candidate datastore are from its previous session or some other user, > which results in it going into an exception-handler (potentially > involving end-user approval) > > It would be much cleaner if NetConf could provide an auto-rollback > guarantee to handling dropped sessions. For instance, something > like: > > > > ... > > > > At least then an app can be sure that the contents in the candidate > datastore are not leftover from its own editing session and hence > warranting the end-user approval to > > What do you think? > This is a specific feature, that has little to do with . Rollback as a feature was rejected by the WG for various reasons. I would rather have a coherent NETCONF verb set, which includes rollback, but this XML attribute for is not it. But until then, a band-aid could help... IMO, a separate operation , could be invoked if this behavior was desired. The manager could invoke this before any , and if its session got terminated for any reason, a will be invoked at termination time. > Thanks, > Kent Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 14:17:19 2008 Return-Path: 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 5DE193A6893; Wed, 30 Jul 2008 14:17:19 -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 5B37C3A6893 for ; Wed, 30 Jul 2008 14:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] 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 f5AT+Nojr7dA for ; Wed, 30 Jul 2008 14:17:17 -0700 (PDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by core3.amsl.com (Postfix) with SMTP id 6FA8E3A6840 for ; Wed, 30 Jul 2008 14:17:17 -0700 (PDT) Received: (qmail 50631 invoked from network); 30 Jul 2008 21:17:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 21:17:30 -0000 X-YMail-OSG: PPYRtzcVM1mctDNOgB6ArIrArTa1CXYAC1A_EUF_Bin6vWXp3eLHBXgVcbzDVHiUb6_qX.pNVnIk4x.Z9E70_GgD8_A3Yvu_6wemnLNq6A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890DA68.8040201@netconfcentral.com> Date: Wed, 30 Jul 2008 14:17:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: > Section 7.5 (i.e. "") of the NetConf spec reads: > > A lock MUST not be granted if either of the following conditions > is true: > > * A lock is already held by any NETCONF session or another > entity. > > > * The target configuration is , it has already been > modified, and these changes have not been committed or rolled > back. > > > The 2nd bullet-point can lead to an app wedging itself when its own > editing session drops unexpectedly, prior to it executing , and > thus leaving contents in the candidate datastore. > > This is a problem because the app can't be sure that the contents in the > candidate datastore are from its previous session or some other user, > which results in it going into an exception-handler (potentially > involving end-user approval) > > It would be much cleaner if NetConf could provide an auto-rollback > guarantee to handling dropped sessions. For instance, something > like: > > > > ... > > > > At least then an app can be sure that the contents in the candidate > datastore are not leftover from its own editing session and hence > warranting the end-user approval to > > What do you think? > This is a specific feature, that has little to do with . Rollback as a feature was rejected by the WG for various reasons. I would rather have a coherent NETCONF verb set, which includes rollback, but this XML attribute for is not it. But until then, a band-aid could help... IMO, a separate operation , could be invoked if this behavior was desired. The manager could invoke this before any , and if its session got terminated for any reason, a will be invoked at termination time. > Thanks, > Kent Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 14:28:33 2008 Return-Path: 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 4BF743A6AF4; Wed, 30 Jul 2008 14:28:33 -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 27C9E3A6A74 for ; Wed, 30 Jul 2008 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 0VwGjxmol8P2 for ; Wed, 30 Jul 2008 14:28:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4421B3A6B0D for ; Wed, 30 Jul 2008 14:28:31 -0700 (PDT) Received: from localhost (unknown [130.129.65.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CFF4376C227; Wed, 30 Jul 2008 23:28:45 +0200 (CEST) Date: Wed, 30 Jul 2008 22:28:31 +0100 (IST) Message-Id: <20080730.222831.175342976.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Kent Watsen" wrote: > It would be much cleaner if NetConf could provide an auto-rollback > guarantee to handling dropped sessions. Section 8.3.5.2 says: When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. Doesn't this cover what you're asking for? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 14:28:33 2008 Return-Path: X-Original-To: netconf-archive@lists.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 4BF743A6AF4; Wed, 30 Jul 2008 14:28:33 -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 27C9E3A6A74 for ; Wed, 30 Jul 2008 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 0VwGjxmol8P2 for ; Wed, 30 Jul 2008 14:28:31 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4421B3A6B0D for ; Wed, 30 Jul 2008 14:28:31 -0700 (PDT) Received: from localhost (unknown [130.129.65.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CFF4376C227; Wed, 30 Jul 2008 23:28:45 +0200 (CEST) Date: Wed, 30 Jul 2008 22:28:31 +0100 (IST) Message-Id: <20080730.222831.175342976.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Kent Watsen" wrote: > It would be much cleaner if NetConf could provide an auto-rollback > guarantee to handling dropped sessions. Section 8.3.5.2 says: When a client fails with outstanding changes to the candidate configuration, recovery can be difficult. To facilitate easy recovery, any outstanding changes are discarded when the lock is released, whether explicitly with the operation or implicitly from session failure. Doesn't this cover what you're asking for? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 14:36:12 2008 Return-Path: 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 7EEC83A686C; Wed, 30 Jul 2008 14:36:12 -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 0D5763A67A6 for ; Wed, 30 Jul 2008 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] 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 7devPlJCFLN4 for ; Wed, 30 Jul 2008 14:36:11 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 155B43A686C for ; Wed, 30 Jul 2008 14:36:11 -0700 (PDT) Received: (qmail 93646 invoked from network); 30 Jul 2008 21:36:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 21:36:25 -0000 X-YMail-OSG: HVLWybEVM1n.tgHU0ju83YyenX0DqlAGtgLMpG.ZHw2KMhEE.3TJGxWRScgmHB2j6OJqneoL6SbxF34g.m.BWiR5xBmWjkSLXducrqQJOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890DED7.5090107@netconfcentral.com> Date: Wed, 30 Jul 2008 14:36:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <4890DA68.8040201@netconfcentral.com> In-Reply-To: <4890DA68.8040201@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Kent Watsen wrote: >> Section 7.5 (i.e. "") of the NetConf spec reads: >> >> A lock MUST not be granted if either of the following conditions >> is true: >> >> * A lock is already held by any NETCONF session or another >> entity. >> >> >> * The target configuration is , it has already been >> modified, and these changes have not been committed or rolled >> back. >> >> >> The 2nd bullet-point can lead to an app wedging itself when its own >> editing session drops unexpectedly, prior to it executing , and >> thus leaving contents in the candidate datastore. >> >> This is a problem because the app can't be sure that the contents in the >> candidate datastore are from its previous session or some other user, >> which results in it going into an exception-handler (potentially >> involving end-user approval) >> >> It would be much cleaner if NetConf could provide an auto-rollback >> guarantee to handling dropped sessions. For instance, something >> like: >> >> >> ... >> >> >> >> At least then an app can be sure that the contents in the candidate >> datastore are not leftover from its own editing session and hence >> warranting the end-user approval to >> >> What do you think? >> > > This is a specific feature, that has little > to do with . Rollback as a feature was rejected > by the WG for various reasons. I would rather have a > coherent NETCONF verb set, which includes rollback, > but this XML attribute for is not it. > > But until then, a band-aid could help... > > IMO, a separate operation , > could be invoked if this behavior was desired. The > manager could invoke this before any , > and if its session got terminated for any reason, > a will be invoked at termination time. > Actually, this doesn't work for the same reason your proposal doesn't work. What matters is the session *before* the one that gets the denied. You cannot be sure if the dirty buffer was left behind intentionally or by mistake. Martin pointed out that if the previous session did take out a lock, then the agent would have already cleaned up, the would be clean, and a new will succeed. > >> Thanks, >> Kent > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 14:36:12 2008 Return-Path: X-Original-To: netconf-archive@lists.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 7EEC83A686C; Wed, 30 Jul 2008 14:36:12 -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 0D5763A67A6 for ; Wed, 30 Jul 2008 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] 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 7devPlJCFLN4 for ; Wed, 30 Jul 2008 14:36:11 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 155B43A686C for ; Wed, 30 Jul 2008 14:36:11 -0700 (PDT) Received: (qmail 93646 invoked from network); 30 Jul 2008 21:36:26 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 21:36:25 -0000 X-YMail-OSG: HVLWybEVM1n.tgHU0ju83YyenX0DqlAGtgLMpG.ZHw2KMhEE.3TJGxWRScgmHB2j6OJqneoL6SbxF34g.m.BWiR5xBmWjkSLXducrqQJOg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890DED7.5090107@netconfcentral.com> Date: Wed, 30 Jul 2008 14:36:23 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <4890DA68.8040201@netconfcentral.com> In-Reply-To: <4890DA68.8040201@netconfcentral.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Kent Watsen wrote: >> Section 7.5 (i.e. "") of the NetConf spec reads: >> >> A lock MUST not be granted if either of the following conditions >> is true: >> >> * A lock is already held by any NETCONF session or another >> entity. >> >> >> * The target configuration is , it has already been >> modified, and these changes have not been committed or rolled >> back. >> >> >> The 2nd bullet-point can lead to an app wedging itself when its own >> editing session drops unexpectedly, prior to it executing , and >> thus leaving contents in the candidate datastore. >> >> This is a problem because the app can't be sure that the contents in the >> candidate datastore are from its previous session or some other user, >> which results in it going into an exception-handler (potentially >> involving end-user approval) >> >> It would be much cleaner if NetConf could provide an auto-rollback >> guarantee to handling dropped sessions. For instance, something >> like: >> >> >> ... >> >> >> >> At least then an app can be sure that the contents in the candidate >> datastore are not leftover from its own editing session and hence >> warranting the end-user approval to >> >> What do you think? >> > > This is a specific feature, that has little > to do with . Rollback as a feature was rejected > by the WG for various reasons. I would rather have a > coherent NETCONF verb set, which includes rollback, > but this XML attribute for is not it. > > But until then, a band-aid could help... > > IMO, a separate operation , > could be invoked if this behavior was desired. The > manager could invoke this before any , > and if its session got terminated for any reason, > a will be invoked at termination time. > Actually, this doesn't work for the same reason your proposal doesn't work. What matters is the session *before* the one that gets the denied. You cannot be sure if the dirty buffer was left behind intentionally or by mistake. Martin pointed out that if the previous session did take out a lock, then the agent would have already cleaned up, the would be clean, and a new will succeed. > >> Thanks, >> Kent > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 15:41:38 2008 Return-Path: X-Original-To: netconf-archive@lists.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 802D63A69EE; Wed, 30 Jul 2008 15:41:38 -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 C9A9B3A69EE for ; Wed, 30 Jul 2008 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 uiNX8dAykBc5 for ; Wed, 30 Jul 2008 15:41:37 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 04EF33A689D for ; Wed, 30 Jul 2008 15:41:36 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 15:41:19 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:41:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:41:20 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 15:41:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:40:21 -0700 Message-ID: In-Reply-To: <20080730.222831.175342976.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Enhancement proposal for NetConf's thread-index: Acjyi0D7wPUaIuCYQZKDNsveV17d1AABzJPQ References: <20080730.222831.175342976.mbj@tail-f.com> From: "Kent Watsen" To: "Martin Bjorklund" X-OriginalArrivalTime: 30 Jul 2008 22:41:20.0075 (UTC) FILETIME=[62BE59B0:01C8F295] Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, July 30, 2008 5:29 PM > To: Kent Watsen > Cc: netconf@ietf.org > Subject: Re: [Netconf] Enhancement proposal for NetConf's > > Hi, > > "Kent Watsen" wrote: > > It would be much cleaner if NetConf could provide an auto-rollback > > guarantee to handling dropped sessions. > > Section 8.3.5.2 says: > > When a client fails with outstanding changes to the candidate > configuration, recovery can be difficult. To facilitate easy > recovery, any outstanding changes are discarded when the lock is > released, whether explicitly with the operation or > implicitly from session failure. > > > > Doesn't this cover what you're asking for? > > /martin Wow, I do not know how I missed that - exactly where Andy said it should be... sorry for the wasted bandwidth! Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 15:41:38 2008 Return-Path: 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 802D63A69EE; Wed, 30 Jul 2008 15:41:38 -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 C9A9B3A69EE for ; Wed, 30 Jul 2008 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 uiNX8dAykBc5 for ; Wed, 30 Jul 2008 15:41:37 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 04EF33A689D for ; Wed, 30 Jul 2008 15:41:36 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 15:41:19 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:41:20 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:41:20 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 15:41:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:40:21 -0700 Message-ID: In-Reply-To: <20080730.222831.175342976.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Enhancement proposal for NetConf's thread-index: Acjyi0D7wPUaIuCYQZKDNsveV17d1AABzJPQ References: <20080730.222831.175342976.mbj@tail-f.com> From: "Kent Watsen" To: "Martin Bjorklund" X-OriginalArrivalTime: 30 Jul 2008 22:41:20.0075 (UTC) FILETIME=[62BE59B0:01C8F295] Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, July 30, 2008 5:29 PM > To: Kent Watsen > Cc: netconf@ietf.org > Subject: Re: [Netconf] Enhancement proposal for NetConf's > > Hi, > > "Kent Watsen" wrote: > > It would be much cleaner if NetConf could provide an auto-rollback > > guarantee to handling dropped sessions. > > Section 8.3.5.2 says: > > When a client fails with outstanding changes to the candidate > configuration, recovery can be difficult. To facilitate easy > recovery, any outstanding changes are discarded when the lock is > released, whether explicitly with the operation or > implicitly from session failure. > > > > Doesn't this cover what you're asking for? > > /martin Wow, I do not know how I missed that - exactly where Andy said it should be... sorry for the wasted bandwidth! Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 15:52:23 2008 Return-Path: X-Original-To: netconf-archive@lists.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 1FE503A686C; Wed, 30 Jul 2008 15:52:23 -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 A0EDD3A686C for ; Wed, 30 Jul 2008 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] 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 HGEBA42psf3A for ; Wed, 30 Jul 2008 15:52:14 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id BFD563A6893 for ; Wed, 30 Jul 2008 15:52:13 -0700 (PDT) Received: (qmail 93344 invoked from network); 30 Jul 2008 22:52:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 22:52:27 -0000 X-YMail-OSG: ehpVqMEVM1n30Y5J3TBRC_ZM8iNNI6UcvZHcuRGoh3HGttFkHeneu5d0dvlxoBbOlDeh2XQQjxE38eHSQZblbt5qrBs6I0E3YZK581MmkQ9YDQ.FP5XULBlzpRt4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890F0A9.7090907@netconfcentral.com> Date: Wed, 30 Jul 2008 15:52:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <20080730.222831.175342976.mbj@tail-f.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: > >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: Wednesday, July 30, 2008 5:29 PM >> To: Kent Watsen >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Enhancement proposal for NetConf's >> >> Hi, >> >> "Kent Watsen" wrote: >>> It would be much cleaner if NetConf could provide an auto-rollback >>> guarantee to handling dropped sessions. >> Section 8.3.5.2 says: >> >> When a client fails with outstanding changes to the candidate >> configuration, recovery can be difficult. To facilitate easy >> recovery, any outstanding changes are discarded when the lock is >> released, whether explicitly with the operation or >> implicitly from session failure. >> >> >> >> Doesn't this cover what you're asking for? >> >> /martin > > Wow, I do not know how I missed that - exactly where Andy said it should > be... sorry for the wasted bandwidth! > Actually, that was Martin. Don't worry about it -- he is always finding stuff the rest of us miss... > Thanks, > Kent Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailmanFrom netconf-bounces@ietf.org Wed Jul 30 15:52:23 2008 Return-Path: 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 1FE503A686C; Wed, 30 Jul 2008 15:52:23 -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 A0EDD3A686C for ; Wed, 30 Jul 2008 15:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] 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 HGEBA42psf3A for ; Wed, 30 Jul 2008 15:52:14 -0700 (PDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by core3.amsl.com (Postfix) with SMTP id BFD563A6893 for ; Wed, 30 Jul 2008 15:52:13 -0700 (PDT) Received: (qmail 93344 invoked from network); 30 Jul 2008 22:52:29 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 22:52:27 -0000 X-YMail-OSG: ehpVqMEVM1n30Y5J3TBRC_ZM8iNNI6UcvZHcuRGoh3HGttFkHeneu5d0dvlxoBbOlDeh2XQQjxE38eHSQZblbt5qrBs6I0E3YZK581MmkQ9YDQ.FP5XULBlzpRt4 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890F0A9.7090907@netconfcentral.com> Date: Wed, 30 Jul 2008 15:52:25 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <20080730.222831.175342976.mbj@tail-f.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: > >> -----Original Message----- >> From: Martin Bjorklund [mailto:mbj@tail-f.com] >> Sent: Wednesday, July 30, 2008 5:29 PM >> To: Kent Watsen >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Enhancement proposal for NetConf's >> >> Hi, >> >> "Kent Watsen" wrote: >>> It would be much cleaner if NetConf could provide an auto-rollback >>> guarantee to handling dropped sessions. >> Section 8.3.5.2 says: >> >> When a client fails with outstanding changes to the candidate >> configuration, recovery can be difficult. To facilitate easy >> recovery, any outstanding changes are discarded when the lock is >> released, whether explicitly with the operation or >> implicitly from session failure. >> >> >> >> Doesn't this cover what you're asking for? >> >> /martin > > Wow, I do not know how I missed that - exactly where Andy said it should > be... sorry for the wasted bandwidth! > Actually, that was Martin. Don't worry about it -- he is always finding stuff the rest of us miss... > Thanks, > Kent Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listi/listinfo/netconf nfo/netconf From netconf-bounces@ietf.org Wed Jul 30 15:57:59 2008 Return-Path: X-Original-To: netconf-archive@lists.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 40B583A68E6; Wed, 30 Jul 2008 15:57:59 -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 AE9EE3A68E6 for ; Wed, 30 Jul 2008 15:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8xifDgZNX-k9 for ; Wed, 30 Jul 2008 15:57:58 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 229AB3A6893 for ; Wed, 30 Jul 2008 15:57:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 15:58:08 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:58:05 -0700 Message-ID: In-Reply-To: <4890F0A9.7090907@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Enhancement proposal for NetConf's thread-index: AcjylvKR9pfwJvlSTeuSHrnRQr33uwAAIE2A References: <20080730.222831.175342976.mbj@tail-f.com> <4890F0A9.7090907@netconfcentral.com> From: "Kent Watsen" To: "Andy Bierman" X-OriginalArrivalTime: 30 Jul 2008 22:58:06.0190 (UTC) FILETIME=[BA6F50E0:01C8F297] Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Actually, that was Martin. > Don't worry about it -- he is always finding stuff > the rest of us miss... No, I mean you said in your first response "This is a specific feature" and that's exactly where Martin found it in the spec :) Cheers, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 15:57:59 2008 Return-Path: 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 40B583A68E6; Wed, 30 Jul 2008 15:57:59 -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 AE9EE3A68E6 for ; Wed, 30 Jul 2008 15:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 8xifDgZNX-k9 for ; Wed, 30 Jul 2008 15:57:58 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 229AB3A6893 for ; Wed, 30 Jul 2008 15:57:56 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 15:58:08 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 Received: from antitop.jnpr.net ([172.24.15.27]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 15:58:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 15:58:05 -0700 Message-ID: In-Reply-To: <4890F0A9.7090907@netconfcentral.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Enhancement proposal for NetConf's thread-index: AcjylvKR9pfwJvlSTeuSHrnRQr33uwAAIE2A References: <20080730.222831.175342976.mbj@tail-f.com> <4890F0A9.7090907@netconfcentral.com> From: "Kent Watsen" To: "Andy Bierman" X-OriginalArrivalTime: 30 Jul 2008 22:58:06.0190 (UTC) FILETIME=[BA6F50E0:01C8F297] Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Actually, that was Martin. > Don't worry about it -- he is always finding stuff > the rest of us miss... No, I mean you said in your first response "This is a specific feature" and that's exactly where Martin found it in the spec :) Cheers, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 16:03:15 2008 Return-Path: X-Original-To: netconf-archive@lists.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 4C9A83A697E; Wed, 30 Jul 2008 16:03:15 -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 CEAA83A697E for ; Wed, 30 Jul 2008 16:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 2+AccHBWZCd1 for ; Wed, 30 Jul 2008 16:03:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0E1E53A6893 for ; Wed, 30 Jul 2008 16:03:13 -0700 (PDT) Received: from localhost (unknown [130.129.65.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CB24E76C227; Thu, 31 Jul 2008 01:03:25 +0200 (CEST) Date: Thu, 31 Jul 2008 00:03:24 +0100 (IST) Message-Id: <20080731.000324.236599183.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Kent Watsen" wrote: > BTW, note that some devices may support more than one candidate > datastore and hence the notification would need to indicate the specific > one (not just a const datastore-identifier like "candidate") If a device supports more than one candidate, then that's an extension to NETCONF. rfc4741 specifies that there is one candidate, and it is refered to as in the operations. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 16:03:15 2008 Return-Path: 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 4C9A83A697E; Wed, 30 Jul 2008 16:03:15 -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 CEAA83A697E for ; Wed, 30 Jul 2008 16:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 2+AccHBWZCd1 for ; Wed, 30 Jul 2008 16:03:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0E1E53A6893 for ; Wed, 30 Jul 2008 16:03:13 -0700 (PDT) Received: from localhost (unknown [130.129.65.56]) by mail.tail-f.com (Postfix) with ESMTPSA id CB24E76C227; Thu, 31 Jul 2008 01:03:25 +0200 (CEST) Date: Thu, 31 Jul 2008 00:03:24 +0100 (IST) Message-Id: <20080731.000324.236599183.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <713043CE8B8E1348AF3C546DBE02C1B4155A2567@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4159CE9FC@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: I-DAction:draft-chisholm-netconf-not-content-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Kent Watsen" wrote: > BTW, note that some devices may support more than one candidate > datastore and hence the notification would need to indicate the specific > one (not just a const datastore-identifier like "candidate") If a device supports more than one candidate, then that's an extension to NETCONF. rfc4741 specifies that there is one candidate, and it is refered to as in the operations. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 16:16:54 2008 Return-Path: X-Original-To: netconf-archive@lists.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 D37F23A67AC; Wed, 30 Jul 2008 16:16:54 -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 383F53A67AA for ; Wed, 30 Jul 2008 16:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] 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 YN+pxr-eGN6X for ; Wed, 30 Jul 2008 16:16:53 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 4CBCB3A68A1 for ; Wed, 30 Jul 2008 16:16:53 -0700 (PDT) Received: (qmail 86675 invoked from network); 30 Jul 2008 23:17:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 23:17:07 -0000 X-YMail-OSG: uqFzoS0VM1lwGQcXFJMkp8EZqSRC54uULd.f906iU0WjfHuwkRK6EpbhHAZGLUqF67utwePLLfjqXJFlD9WVWZGUVGlv5qAzDQYy2vmUPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890F670.6070005@netconfcentral.com> Date: Wed, 30 Jul 2008 16:17:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <20080730.222831.175342976.mbj@tail-f.com> <4890F0A9.7090907@netconfcentral.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: >> Actually, that was Martin. >> Don't worry about it -- he is always finding stuff >> the rest of us miss... > > No, I mean you said in your first response "This is a > specific feature" and that's exactly where Martin found it in the spec > :) > The NETCONF WG may want to reconsider the 'capability document template' approach in RFC 4741. It may not be intuitive for the reader to gather bits of data for each verb, partitioned by capability. BTW, I do not really want a new protocol spec published yet. This is a super-low priority. I prefer instead to continue using the capability extension approach (e.g., Notifications, partial-lock, with-defaults). After some experience with that 'content' thing, we can roll up all the various capabilities in the 'base2' capability, defined in 4741-bis. > Cheers, > Kent > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jul 30 16:16:54 2008 Return-Path: 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 D37F23A67AC; Wed, 30 Jul 2008 16:16:54 -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 383F53A67AA for ; Wed, 30 Jul 2008 16:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] 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 YN+pxr-eGN6X for ; Wed, 30 Jul 2008 16:16:53 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 4CBCB3A68A1 for ; Wed, 30 Jul 2008 16:16:53 -0700 (PDT) Received: (qmail 86675 invoked from network); 30 Jul 2008 23:17:08 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.134 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 30 Jul 2008 23:17:07 -0000 X-YMail-OSG: uqFzoS0VM1lwGQcXFJMkp8EZqSRC54uULd.f906iU0WjfHuwkRK6EpbhHAZGLUqF67utwePLLfjqXJFlD9WVWZGUVGlv5qAzDQYy2vmUPw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4890F670.6070005@netconfcentral.com> Date: Wed, 30 Jul 2008 16:17:04 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Kent Watsen References: <20080730.222831.175342976.mbj@tail-f.com> <4890F0A9.7090907@netconfcentral.com> In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Enhancement proposal for NetConf's X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Kent Watsen wrote: >> Actually, that was Martin. >> Don't worry about it -- he is always finding stuff >> the rest of us miss... > > No, I mean you said in your first response "This is a > specific feature" and that's exactly where Martin found it in the spec > :) > The NETCONF WG may want to reconsider the 'capability document template' approach in RFC 4741. It may not be intuitive for the reader to gather bits of data for each verb, partitioned by capability. BTW, I do not really want a new protocol spec published yet. This is a super-low priority. I prefer instead to continue using the capability extension approach (e.g., Notifications, partial-lock, with-defaults). After some experience with that 'content' thing, we can roll up all the various capabilities in the 'base2' capability, defined in 4741-bis. > Cheers, > Kent > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf