From hartmans@mit.edu Wed Jun 3 12:22:38 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849503A7062; Wed, 3 Jun 2009 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 cT5KwwNl5Yxx; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 37D063A6929; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4DB484141; Wed, 3 Jun 2009 15:22:30 -0400 (EDT) To: ietf@ietf.org References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: Sam Hartman Date: Wed, 03 Jun 2009 15:22:30 -0400 In-Reply-To: <20090519133936.DC6B63A6AC0@core3.amsl.com> (The IESG's message of "Tue\, 19 May 2009 06\:39\:36 -0700 \(PDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 03 Jun 2009 14:04:34 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:22:38 -0000 I was assigned this document as a secdir review. I'm not sure I have any comments in that capacity. However, I do have significant comments on the last call of this document. I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: * It does not reflect practices across significant areas of the IETF * It does not provide clear, actionable guidelines * It is not sufficiently clear to be understood outside the O&M area. My background. I have never formally been involved in the O&M area. However, I have studied SNMP as a participant and AD for the ISMS Wg. I have studied syslog as a user, operator, and as the AD who sponsored many of syslog's base documents. I have studied netconf as an AD who reviewed the spec. I've worked as a small enterprise operator. I'm a chair of a WG (LISP) that needs to consider operations and management issues. I believe that I should be able to read and understand this document; I believe that I'm well within its target audience. I got as far as the bottom of page 18 before giving up. Here are details on my concerns based on what part of the document I've read. I'm happy to invest significant time to get other reviewers to evaluate whether I have valid concerns; if I get others to read the document and consider whether I have a point, then I've done what I set out to do. 1) It does not reflect practices across significant areas of the IETF This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM implementors, etc do not want management interoperability. I understand that ISP operators very much do want management interoperability. I think that we have a significant conflict here and I think that we cannot approve such a BCP without addressing that conflict. One possible resolution would be to find an subsection of the IETF that actually agrees with these guidelines and scoping the BCP. Similarly, it has been my experience that the desire to standardize information model semantics is not universal across the IETF. My recommendation for determining if I have a valid concern here is to get one or two WG chairs from each area to read this document and comment explicitly on whether the approach to management and managability outlined in this document is consistent with practice in their area and WG. Far too much of the text was specific to management of network elements such as routers, switches and the like. The apps and security area use LDAP for a lot of things that I think would count as management in this spec. I don't know how to separate control plane and data plane issues on my web server. Enough of the text seemed specific to network management instead of service/application management that I would find applying this document in such a context more frustrating than helpful. This specific sub-concern could be entirely addressed by properly scoping the applicability of the document. 2) It does not provide clear, actionable guidelines I was looking at this document and trying to figure out what it would mean for my WG if this document was approved. As best I can tell it would simply add justifications for discusses that would be hard to debate fairly. Do I have to write up an information model for my protocol? If the ops AD says I do, what grounds do we use to determine whether that's reasonable? The answer may be "yes and you don't get to disagree," but I can't tell from the document. If it's going to be a BCP, that needs to be clear to me as a WG chair. For what it's worth, I don't think we have the necessary consensus to require people to write up information models and would not be part of such a consensus at this time. If this is a list of things I might want to consider then why is it a BCP? If we want to come up with a set of things that need to be documented when appropriate, then I could support that. I think we need to clearly distinguish the normative process requirements from the set of things to consider in such a case. The set of things someone might interpret as normative in this spec is far too broad. I do agree that some of the concerns I am raising in this section could be leveled against BCPs we've approved in the past--even BCPs that I sponsored in at least one case. I don't think that diminishes the concerns: we try and learn from our mistakes. 3) It is not sufficiently clear to be understood outside the O&M area. This document does an excellent job of clearing up a few o&m concepts: the difference between information model, data model, modeling language and protocol. The document indicates that several distinctions are important, such as the distinction between operations and management, the distinction between configuration and other forms of management, etc. The configuration vs non-configuration management distinction seems very important because I believe there is a growing belief that the set of management protocols you use depends on what you are managing. I hope no one plans to use syslog to configure their routers--perhaps the only worse choice would be IPFIX. Unfortunately, while I agree that these distinctions are important, I don't think the document succeeds in making them. I have reread section 2 and the first part of section 3 a couple of times. I still don't understand the difference between operations and management; section two talks about management a lot and section 3 talks about my operations model. I don't understand what an operations model is, even after reading the text a couple of times. I found section 3 very frustrating. I'd be reading along thinking I was talking about management for one purpose, thinking about how that interacted with protocols for that purpose, and then suddenly something gets thrown in that completely fails to fit. For example, I'd be thinking about how to manage configuration state and then suddenly I'm being told to define the semantics of my counters consistently. Both of those are fine things to discuss, but not in such a way that a reader gets them mixed together. The mental context swap is too jarring and I found completely lost me. In conclusion, I'm sorry that I could not be more constructive. I really a lot has gone into this document. I realize that the goals are important. However I don't think we're particularly close to done at least if the target is a BCP. From lear@cisco.com Wed Jun 3 23:15:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33E33A6AF6; Wed, 3 Jun 2009 23:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XT2Z411-6axg; Wed, 3 Jun 2009 23:15:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 624A128C1AD; Wed, 3 Jun 2009 23:15:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,303,1241395200"; d="scan'208";a="41992670" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Jun 2009 06:15:27 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n546FRAC014619; Thu, 4 Jun 2009 08:15:27 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-109-26.cisco.com [10.61.109.26]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n546FQRd004841; Thu, 4 Jun 2009 06:15:26 GMT Message-ID: <4A27667E.9020409@cisco.com> Date: Thu, 04 Jun 2009 08:15:26 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Shredder/3.0b3pre MIME-Version: 1.0 To: Sam Hartman References: <20090519133936.DC6B63A6AC0@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10465; t=1244096127; x=1244960127; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-ietf-opsawg-oper ations-and-management=09(Guidelines=0A=20for=20Considering=2 0Operations=20and=20Management=20of=20New=09Protocols=20and= 20Protocol=20Extensions)=0A=20to=20BCP |Sender:=20; bh=a50RQP7wFulYgs4yguzhFsWsoRJtIqs+CtB15EuV2ig=; b=nGXsjbNubrG9i3rCbJqYN/P9i+9tBQ+I/jw7m3ZyMufy1Zb+hFB8p+lkVl Sm2zs6nhg/WmJrR4i50DDM7FONXQgHPa0sPBCuIOJS5WuV79PgHOSE5VjJFM 4fq9MRXLKY; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Mailman-Approved-At: Thu, 04 Jun 2009 00:01:42 -0700 Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 06:15:28 -0000 Sam, Thanks for posting your review. It caused me to have a look at the document, because I've been considering writing something of a missive on my own. I have to say that I enjoyed reading this draft up to about Section 3, and then I came to some problems. I'll spell those out in a separate message, but I agree with you on one key point: this document does not does not provide actionable guidance, and actually avoids the use of 2119 language. Clearly that was a design goal. But I think in the end it has led to a good INFORMATIONAL document, or even the beginnings of a good text book, and not necessarily a BCP. Also, I agree with you that interoperability is not the first and primary goal. Clearly, and I hope Dave and others will agree, the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (or total cost, if you will) for that service. And Section 2 provides a really nice illustration of that, with regard to what happened at Berkeley. I have another problem with 3.2: I think the SMI and other registry-based forms of structured data may be overrated in some cases. Sometimes what is being managed is very simple data, through a central service. One has to question who the consumer of the data is prior to determining how one encodes that data, or even what data is truly necessary. Consider the case of an application that is simply calling home to determine if there are patches. How much structured data does that service need? In this context, 3.2 is often irrelevant to the application running on some host, but it may be very relevant to the central system that is doing the updating. What I would suggest is that some additional context is necessary throughout the document to indicate really who we are talking to. Are we limiting our role to router management? What happened to the toaster with an SNMP stack? Would we use SNMP today for that toaster? Who would manage it? Well, let's put it in a more serious context and swap toaster for major appliance like air conditioner or refrigerator or PDU. Ok, and again. Thanks Dave and others for writing the doc. Eliot On 6/3/09 9:22 PM, Sam Hartman wrote: > I was assigned this document as a secdir review. > I'm not sure I have any comments in that capacity. > > However, I do have significant comments on the last call of this document. > > I appreciate the work that has gone into this document. People have > worked hard to find examples, cases and even pithy > sayings/architectural principles from many areas of the IETF. The > document tries to be broad and to look at a lot of options. I think > that it would be reasonable to publish this document as the current > thinking of the ops WG or ops area. It may even be reasonable to use > something like this as guidelines for network/routing/sub-network > layer protocols to think about management and operations. > However this document is not suitable for publication as a BCP because: > > * It does not reflect practices across significant areas of the IETF > * It does not provide clear, actionable guidelines > * It is not sufficiently clear to be understood outside the O&M area. > > My background. I have never formally been involved in the O&M area. > However, I have studied SNMP as a participant and AD for the ISMS Wg. > I have studied syslog as a user, operator, and as the AD who sponsored > many of syslog's base documents. I have studied netconf as an AD who > reviewed the spec. I've worked as a small enterprise operator. I'm a > chair of a WG (LISP) that needs to consider operations and management > issues. I believe that I should be able to read and understand this > document; I believe that I'm well within its target audience. > > I got as far as the bottom of page 18 before giving up. > > Here are details on my concerns based on what part of the document > I've read. I'm happy to invest significant time to get other > reviewers to evaluate whether I have valid concerns; if I get others > to read the document and consider whether I have a point, then I've > done what I set out to do. > > 1) It does not reflect practices across significant areas of the IETF > > This is a concern that the document does not have broad enough > consensus to be a BCP. I believe that significant areas of the IETF > do not view management interoperability as a goal--much less a guiding > principle of management. I've been involved in discussions in the > Kerberos working group where we explicitly discussed this and came to > the conclusion that management interoperability was not something > anyone in the room was going to work on. We did work on an > information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. > > > Similarly, I'm quite certain that most web server vendors, ATOM > implementors, etc do not want management interoperability. I > understand that ISP operators very much do want management > interoperability. I think that we have a significant conflict here > and I think that we cannot approve such a BCP without addressing that > conflict. One possible resolution would be to find an subsection of > the IETF that actually agrees with these guidelines and scoping the > BCP. > > Similarly, it has been my experience that the desire to standardize > information model semantics is not universal across the IETF. > > My recommendation for determining if I have a valid concern here is to > get one or two WG chairs from each area to read this document and > comment explicitly on whether the approach to management and > managability outlined in this document is consistent with practice in > their area and WG. > > Far too much of the text was specific to management of network > elements such as routers, switches and the like. The apps and > security area use LDAP for a lot of things that I think would count as > management in this spec. I don't know how to separate control plane > and data plane issues on my web server. Enough of the text seemed > specific to network management instead of service/application > management that I would find applying this document in such a context > more frustrating than helpful. This specific sub-concern could be > entirely addressed by properly scoping the applicability of the > document. > > > 2) It does not provide clear, actionable guidelines > > I was looking at this document and trying to figure out what it would > mean for my WG if this document was approved. As best I can tell it > would simply add justifications for discusses that would be hard to > debate fairly. Do I have to write up an information model for my > protocol? If the ops AD says I do, what grounds do we use to > determine whether that's reasonable? The answer may be "yes and you > don't get to disagree," but I can't tell from the document. If it's > going to be a BCP, that needs to be clear to me as a WG chair. > > For what it's worth, I don't think we have the necessary consensus to > require people to write up information models and would not be part of > such a consensus at this time. If this is a list of things I might > want to consider then why is it a BCP? > > If we want to come up with a set of things that need to be documented > when appropriate, then I could support that. I think we need to > clearly distinguish the normative process requirements from the set of > things to consider in such a case. The set of things someone might > interpret as normative in this spec is far too broad. > > I do agree that > some of the concerns I am raising in this section could be leveled > against BCPs we've approved in the past--even BCPs that I sponsored in > at least one case. I don't think that diminishes the concerns: we try > and learn from our mistakes. > > 3) It is not sufficiently clear to be understood outside the O&M area. > > This document does an excellent job of clearing up a few o&m concepts: > the difference between information model, data model, modeling > language and protocol. > > The document indicates that several distinctions are important, such > as the distinction between operations and management, the distinction > between configuration and other forms of management, etc. The > configuration vs non-configuration management distinction seems very > important because I believe there is a growing belief that the set of > management protocols you use depends on what you are managing. I hope > no one plans to use syslog to configure their routers--perhaps the > only worse choice would be IPFIX. > > Unfortunately, while I agree that these distinctions are important, I > don't think the document succeeds in making them. I have reread > section 2 and the first part of section 3 a couple of times. I still > don't understand the difference between operations and management; > section two talks about management a lot and section 3 talks about > my operations model. I don't understand what an operations model is, > even after reading the text a couple of times. > > I found section 3 very frustrating. I'd be reading along thinking I > was talking about management for one purpose, thinking about how that > interacted with protocols for that purpose, and then suddenly > something gets thrown in that completely fails to fit. For example, > I'd be thinking about how to manage configuration state and then > suddenly I'm being told to define the semantics of my counters > consistently. Both of those are fine things to discuss, but not in > such a way that a reader gets them mixed together. The mental context > swap is too jarring and I found completely lost me. > > In conclusion, I'm sorry that I could not be more constructive. I > really a lot has gone into this document. I realize that the goals > are important. However I don't think we're particularly close to done > at least if the target is a BCP. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > From sm@resistor.net Wed Jun 3 23:44:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A423A6C4C; Wed, 3 Jun 2009 23:44:12 -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 ydIX8AwTB9wo; Wed, 3 Jun 2009 23:44:11 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A31773A68E3; Wed, 3 Jun 2009 23:44:11 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n546i1LR029079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 23:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1244097850; x=1244184250; bh=Wuhf+WDmnsO0cpTkLFcL0nXS0fPFDwAEQKjRJk9succ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=L8iOAaGxjRcVUjg+62lzU4feh26IWC8sLcOLCdVKHVhgc1M2x0ZdBH7dY8307GXn0 Wi57n7ZhhMLoC5miehjyOARLvFsII7fNzbhWLe9TGGnhTnGgNjVkmw+pVwl1cbqBRZ tR7MEm+MOK9qP4bitauA4B9/klZRPeCrXK+khlCE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=YAH1dJu3XWzW05pQNLMpZ/lXs9iIF68gzg/csCB/KsusE/TZidnjIJ1aMI7nT7zRI iYqOfvARhXvM0My9AO+J5k9EIcqEhqmJS1DuDcPuACSxHQh/twCus/0rbUKQjN/Cdq0 /sendJ24QbRnvUjRU/OT1co1727Lhd41cU2PQuA= Message-Id: <6.2.5.6.2.20090603213550.02a8b970@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Jun 2009 22:22:23 -0700 To: Sam Hartman , ietf@ietf.org From: SM In-Reply-To: References: <20090519133936.DC6B63A6AC0@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 04 Jun 2009 00:01:42 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 06:44:12 -0000 At 12:22 03-06-2009, Sam Hartman wrote: >I appreciate the work that has gone into this document. People have >worked hard to find examples, cases and even pithy >sayings/architectural principles from many areas of the IETF. The >document tries to be broad and to look at a lot of options. I think >that it would be reasonable to publish this document as the current >thinking of the ops WG or ops area. It may even be reasonable to use >something like this as guidelines for network/routing/sub-network >layer protocols to think about management and operations. >However this document is not suitable for publication as a BCP because: The document is a good piece of work. The considerations discussed in it may help other areas understand the thinking of the ops area as management and operations considerations are often overlooked. Bernard Aboba posted some interesting comments on Section 1 of this draft for the Last Call. I don't think that the document scales well from an IETF perspective as a BCP. As such, I do not support its publication as a BCP. Regards, -sm From dromasca@avaya.com Thu Jun 4 00:07:38 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBB53A6904 for ; Thu, 4 Jun 2009 00:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 YDLbptgy4Qqn for ; Thu, 4 Jun 2009 00:07:37 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 2F4BA3A6B22 for ; Thu, 4 Jun 2009 00:07:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,304,1241409600"; d="scan'208";a="163284195" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 Jun 2009 03:07:38 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Jun 2009 03:07:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 09:07:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-opsawg-operations-and-management-07.txt Thread-Index: AcnivggrQVxOD7XOS4akwbSn/wVlJQCJQ1iA From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] FW: Gen-ART review of draft-ietf-opsawg-operations-and-management-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 07:07:38 -0000 =20 -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]=20 Sent: Monday, June 01, 2009 4:36 PM To: dharrington@huawei.com; Romascanu, Dan (Dan) Cc: opsawg-chairs@tools.ietf.org; General Area Review Team Subject: Gen-ART review of draft-ietf-opsawg-operations-and-management-07.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-operations-and-management-07.txt Reviewer: Miguel Garcia Review Date: 01-June-2009 IETF LC End Date: 02-June-2009 Summary: The document is ready for publication as a BCP. Major issues: none Minor issues: none Nits/editorial comments: A few nits, if you have a chance to bring to the document. - Spelling errors: Page 5: s/Informatiion/Information Page 9: capitalize "it" in "it is extremely important..." - Expand acronyms at first occurrence and add a reference to them (if they are documents). This includes: SNMP, SYSLOG, COPS, XML, RADIUS, DIAMETER, NETCONF, IPFIX, DMTF, TMF, RMON, and NMS. - Although a reference exist later in the text, I would add a reference to RFC 3444 in Section 1.6 in relation with bullet points 1 and 2. - Page 10, Section 2.4. The text talks about a "router alert". I guess you should add a reference to the relevant document that describes "Router alert", presumably RFC 2113 and RFC 2711 - In Section 3.6, page 21, second and third paragraphs talk about existing working groups (BMWG and IPPM) and their deliverables (some "metris", referenced by name not by reference). If we consider a reader of this document some 5 years from now, at that time perhaps those WGs do not exist any longer, and it would be hard to trace the deliverables that this draft is trying to consider. I think it is useless to have a reference by name, because it will be hard to find it when the RFC is published. I think the draft should refer a document, I-D or RFC, with a proper reference. If this cannot be done, the text is mostly useless. - Comment. Section 4.3 discusses the placement of the Operations and Manageability Considerations Section. I think the Instructions to RFC Authors, http://www.rfc-editor.org/howtopub.html should be updated to reflect this draft, especially in the section that discusses the names and titles of sections in an RFC. I know this effort is not part of the author's role, but it should be done by someone at some point in time. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From dromasca@avaya.com Thu Jun 4 02:16:20 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6D93A6C0D; Thu, 4 Jun 2009 02:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 BV5o-Q2u9gpz; Thu, 4 Jun 2009 02:16:19 -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 A20D23A683A; Thu, 4 Jun 2009 02:16:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,304,1241409600"; d="scan'208";a="147622472" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Jun 2009 05:16:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2009 05:16:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 11:16:05 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP Thread-Index: AcnkgLKYD4rY0cCHRfOsXSdJ7EKXaQAcfvQA References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: "Sam Hartman" , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 09:16:20 -0000 Sam, Thank you for your review and opinions.=20 I would like to remind you and let many people that are not aware about the history of the document know one fact that may be important. This document is an outcome of the discussions hold at the IESG retreat in May 2006. I was then the 'fresh' AD bringing this issue to the IESG table, we discussed approaches on dealing with management in the IETF and the need for a different approach of looking at management than the 'write a MIB' which was the rule in the IETF WGs until then. I took the action item to 'write a draft' on this issue - which then developped in this piece of work chartered in the OPSAWG.=20 =20 ... >=20 > This is a concern that the document does not have broad=20 > enough consensus to be a BCP. I believe that significant=20 > areas of the IETF do not view management interoperability as=20 > a goal--much less a guiding principle of management. I've=20 > been involved in discussions in the Kerberos working group=20 > where we explicitly discussed this and came to the conclusion=20 > that management interoperability was not something anyone in=20 > the room was going to work on. We did work on an information=20 > model which covers aspects where people believed some degree=20 > of management interoperability would be desirable. It does=20 > not cover monitoring, faults, or the like--only provisioning=20 > of the database. >=20 >=20 > Similarly, I'm quite certain that most web server vendors,=20 > ATOM implementors, etc do not want management=20 > interoperability. I understand that ISP operators very much=20 > do want management interoperability. I think that we have a=20 > significant conflict here and I think that we cannot approve=20 > such a BCP without addressing that conflict. One possible=20 > resolution would be to find an subsection of the IETF that=20 > actually agrees with these guidelines and scoping the BCP. >=20 > Similarly, it has been my experience that the desire to=20 > standardize information model semantics is not universal=20 > across the IETF. I believe that the document recognizes the variance in approaches for the different areas, protocols, and working groups in the IETF and for this reason rightly avoids making a prescription or imposing a fixed solution or format in dealing with operational considerations and manageability aspects of the IETF protocols. I think that it does make however the point that operational deployment and manageability aspects need to be taken into considerations for any new IETF work. The awareness of these issue should exist in any work the IETF engages with, after all we develop technologies and protocols to be deployed and operated in the real life Internet, not abstract mathematical models. It is fine if a WG decides that its protocol needs not interoperable management or no standardized data model, but this should be the result of discussions and decisions, not of mission.=20 Dan =20 From adrian@olddog.co.uk Thu Jun 4 03:07:35 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE733A68B1; Thu, 4 Jun 2009 03:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_05=-1.11] 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 9Df405WLxD1L; Thu, 4 Jun 2009 03:07:35 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id B9CA23A6811; Thu, 4 Jun 2009 03:07:34 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n54A7HDW021928; Thu, 4 Jun 2009 11:07:22 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n54A7EDg021884; Thu, 4 Jun 2009 11:07:16 +0100 Message-ID: <65560109893A4E21A127CA9CB729841B@your029b8cecfe> From: "Adrian Farrel" To: References: <20090519133936.DC6B63A6AC0@core3.amsl.com> <4A27667E.9020409@cisco.com> Date: Thu, 4 Jun 2009 10:58:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Thu, 04 Jun 2009 03:09:00 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelinesfor Considering Operations and Management of New Protocols and ProtocolExtensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:07:35 -0000 In the discussion of IETF consensus of this document and its position as a BCP or otherwise, can I throw into the melting pot draft-ietf-pce-manageability-requirements-06.txt This particular I-D was developed within the PCE working group to apply only in that working group. It covers similar topics, but is more focused on ensuring that the protocols that are developed in PCE are manageable. The I-D has rough WG consensus (or did at the time I stopped being chair a few months ago), but is not mandatory to implement within the WG. It is my opinion that those PCE I-Ds that have taken the draft on board have produced better solutions that will be more successfully implemented and deployed. Cheers, Adrian From dromasca@avaya.com Thu Jun 4 04:35:34 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC2E3A6915; Thu, 4 Jun 2009 04:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 I6iUXS84uGyd; Thu, 4 Jun 2009 04:35:34 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A70953A69C0; Thu, 4 Jun 2009 04:35:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,305,1241409600"; d="scan'208";a="163304291" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 04 Jun 2009 07:35:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Jun 2009 07:35:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 13:35:06 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP Thread-Index: AcnlBtLfLjx1N/o9RpKubjbgdziKYwAARD7Q References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: "Romascanu, Dan (Dan)" To: "Sam Hartman" Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 11:35:34 -0000 Hi Sam, A clarification and a clarification question in-line. Dan =20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Thursday, June 04, 2009 2:23 PM > To: Romascanu, Dan (Dan) > Cc: Sam Hartman; ietf@ietf.org; opsawg@ietf.org > Subject: Re: Last Call:=20 > draft-ietf-opsawg-operations-and-management(Guidelines for=20 > Considering Operations and Management of NewProtocols and=20 > Protocol Extensions) to BCP >=20 > >>>>> "Dan" =3D=3D Romascanu, Dan (Dan) writes: >=20 > Dan> Sam, Thank you for your review and opinions. >=20 > Dan> I would like to remind you and let many people that are not > Dan> aware about the history of the document know one fact that > Dan> may be important. This document is an outcome of the > Dan> discussions hold at the IESG retreat in May 2006. I was then > Dan> the 'fresh' AD bringing this issue to the IESG table, we > Dan> discussed approaches on dealing with management in the IETF > Dan> and the need for a different approach of looking at > Dan> management than the 'write a MIB' which was the rule in the > Dan> IETF WGs until then. I took the action item to 'write a > Dan> draft' on this issue - which then developped in this piece of > Dan> work chartered in the OPSAWG. > I certainly appreciate the work that has gone into this=20 > draft. I'm not sure why the origins here are important. If=20 > you're saying that it should have special status because the=20 > original discussion happened at the IESG level, I disagree. =20 > If you're saying that the content has broad consensus because=20 > it started at the IESG level, I disagree. If you're saying=20 > that it's important work with a long history, I agree. None of these - just background information to place this document in context.=20 ... >=20 > Dan> and for this reason rightly avoids making > Dan> a prescription or imposing a fixed solution or format in > Dan> dealing with operational considerations and manageability > Dan> aspects of the IETF protocols. I think that it does make > Dan> however the point that operational deployment and > Dan> manageability aspects need to be taken into considerations > Dan> for any new IETF work. The awareness of these issue should > Dan> exist in any work the IETF engages with, after all we develop > Dan> technologies and protocols to be deployed and operated in the > Dan> real life Internet, not abstract mathematical models. It is > Dan> fine if a WG decides that its protocol needs not > Dan> interoperable management or no standardized data model, but > Dan> this should be the result of discussions and decisions, not > Dan> of mission. >=20 >=20 > It's not at all clear to me from this document that would be fine. > That's one of my most serious problems with the document. Can you clarify? I cannot understand what is clear to you and what is not, and with which statement you do not agree.=20 >=20 From hartmans@mit.edu Thu Jun 4 04:23:05 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FFE3A68B1; Thu, 4 Jun 2009 04:23:05 -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.271, 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 7FoXbyFKaCIK; Thu, 4 Jun 2009 04:23:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id EBE8A28C159; Thu, 4 Jun 2009 04:22:59 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DA98B4141; Thu, 4 Jun 2009 07:22:56 -0400 (EDT) To: "Romascanu\, Dan \(Dan\)" References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: Sam Hartman Date: Thu, 04 Jun 2009 07:22:56 -0400 In-Reply-To: (Dan Romascanu's message of "Thu\, 4 Jun 2009 11\:16\:05 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 04 Jun 2009 04:35:43 -0700 Cc: opsawg@ietf.org, Sam Hartman , ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 11:23:05 -0000 >>>>> "Dan" == Romascanu, Dan (Dan) writes: Dan> Sam, Thank you for your review and opinions. Dan> I would like to remind you and let many people that are not Dan> aware about the history of the document know one fact that Dan> may be important. This document is an outcome of the Dan> discussions hold at the IESG retreat in May 2006. I was then Dan> the 'fresh' AD bringing this issue to the IESG table, we Dan> discussed approaches on dealing with management in the IETF Dan> and the need for a different approach of looking at Dan> management than the 'write a MIB' which was the rule in the Dan> IETF WGs until then. I took the action item to 'write a Dan> draft' on this issue - which then developped in this piece of Dan> work chartered in the OPSAWG. I certainly appreciate the work that has gone into this draft. I'm not sure why the origins here are important. If you're saying that it should have special status because the original discussion happened at the IESG level, I disagree. If you're saying that the content has broad consensus because it started at the IESG level, I disagree. If you're saying that it's important work with a long history, I agree. Dan> I believe that the document recognizes the variance in Dan> approaches for the different areas, protocols, and working Dan> groups in the IETF I strongly disagree that it succeeds in this goal. I agree it tries. As an example, section 3.1 says that the primary goal when considering management should be interoperability. That's a broad statement that does not have IETF consensus and is inappropriate for a BCP. Dan> and for this reason rightly avoids making Dan> a prescription or imposing a fixed solution or format in Dan> dealing with operational considerations and manageability Dan> aspects of the IETF protocols. I think that it does make Dan> however the point that operational deployment and Dan> manageability aspects need to be taken into considerations Dan> for any new IETF work. The awareness of these issue should Dan> exist in any work the IETF engages with, after all we develop Dan> technologies and protocols to be deployed and operated in the Dan> real life Internet, not abstract mathematical models. It is Dan> fine if a WG decides that its protocol needs not Dan> interoperable management or no standardized data model, but Dan> this should be the result of discussions and decisions, not Dan> of mission. It's not at all clear to me from this document that would be fine. That's one of my most serious problems with the document. From ietfdbh@comcast.net Thu Jun 4 07:49:20 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EF33A6DB3 for ; Thu, 4 Jun 2009 07:49:20 -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 YBXJdt7F6lzV for ; Thu, 4 Jun 2009 07:49:19 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 632003A6E96 for ; Thu, 4 Jun 2009 07:49:18 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA07.westchester.pa.mail.comcast.net with comcast id zmV71b00217dt5G57qoHWF; Thu, 04 Jun 2009 14:48:17 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id zqpA1b0090UQ6dC3ZqpAkL; Thu, 04 Jun 2009 14:49:10 +0000 From: "David Harrington" To: , , References: Date: Thu, 4 Jun 2009 10:49:09 -0400 Message-ID: <01c401c9e523$9e37c180$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcnivggrQVxOD7XOS4akwbSn/wVlJQCJQ1iAAA8UyrA= Cc: opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] FW: Gen-ART review ofdraft-ietf-opsawg-operations-and-management-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 14:49:20 -0000 Hi, Thank you for the review. comments inline. > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Monday, June 01, 2009 4:36 PM > To: dharrington@huawei.com; Romascanu, Dan (Dan) > Cc: opsawg-chairs@tools.ietf.org; General Area Review Team > Subject: Gen-ART review of > draft-ietf-opsawg-operations-and-management-07.txt > > I have been selected as the General Area Review Team > (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-opsawg-operations-and-management-07.txt > Reviewer: Miguel Garcia Review Date: > 01-June-2009 IETF LC End Date: 02-June-2009 > > Summary: The document is ready for publication as a BCP. > > Major issues: none > > Minor issues: none > > Nits/editorial comments: A few nits, if you have a chance to bring to > the document. > > - Spelling errors: > Page 5: s/Informatiion/Information > Page 9: capitalize "it" in "it is extremely important..." fixed. > > - Expand acronyms at first occurrence and add a reference to them (if > they are documents). This includes: SNMP, SYSLOG, COPS, XML, RADIUS, > DIAMETER, NETCONF, IPFIX, DMTF, TMF, RMON, and NMS. > > - Although a reference exist later in the text, I would add a > reference > to RFC 3444 in Section 1.6 in relation with bullet points 1 and 2. done > > - Page 10, Section 2.4. The text talks about a "router alert". I guess > you should add a reference to the relevant document that describes > "Router alert", presumably RFC 2113 and RFC 2711 done > > - In Section 3.6, page 21, second and third paragraphs talk about > existing working groups (BMWG and IPPM) and their deliverables (some > "metris", referenced by name not by reference). If we > consider a reader > of this document some 5 years from now, at that time perhaps those WGs > do not exist any longer, and it would be hard to trace the > deliverables > that this draft is trying to consider. I think it is useless to have a > reference by name, because it will be hard to find it when the RFC is > published. I think the draft should refer a document, I-D or > RFC, with a > proper reference. If this cannot be done, the text is mostly useless. I modified the text to say "The IETF, via the Benchmarking Methodology WG (BMWG), has defined recommendations..." and added "Search for "benchmark" in the RFC search tool." and "The IETF, via the IP Performance Monitoring (IPPM) WG, has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. The existing metrics might be applicable to the new protocol. Search for "metric" in the RFC search tool." > > - Comment. Section 4.3 discusses the placement of the Operations and > Manageability Considerations Section. I think the Instructions to RFC > Authors, http://www.rfc-editor.org/howtopub.html should be updated to > reflect this draft, especially in the section that discusses the names > and titles of sections in an RFC. I know this effort is not > part of the > author's role, but it should be done by someone at some point in time. That discussion is (deliberately) above my pay grade. ;-) > > /Miguel > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From erosen@cisco.com Thu Jun 4 11:05:43 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E733C3A7083; Thu, 4 Jun 2009 11:05:43 -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 CkhVcgrAeKRN; Thu, 4 Jun 2009 11:05:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id EB5F63A6F7D; Thu, 4 Jun 2009 11:05:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,306,1241395200"; d="scan'208";a="79229948" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2009 18:05:32 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n54I5VCN004150; Thu, 4 Jun 2009 14:05:32 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n54I5V6A022137; Thu, 4 Jun 2009 18:05:31 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n54I5Vxa015970; Thu, 4 Jun 2009 14:05:31 -0400 To: "Romascanu, Dan (Dan)" In-reply-to: References: <20090519133936.DC6B63A6AC0@core3.amsl.com> Comments: In-reply-to "Romascanu, Dan (Dan)" message dated "Thu, 04 Jun 2009 13:35:06 +0200." X-Mailer: MH-E 8.0.3; nmh 1.2; GNU Emacs 22.1.1 Date: Thu, 04 Jun 2009 14:05:31 -0400 Message-ID: <15968.1244138731@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=701; t=1244138732; x=1245002732; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-ietf-opsawg-oper ations-and-management(Guidelines=20for=20Considering=20Opera tions=20and=20Management=20of=20NewProtocols=20and=20Protoco l=20Extensions)=20to=20BCP=20 |Sender:=20 |To:=20=22Romascanu,=20Dan=20(Dan)=22=20; bh=xftHoro+SLGPCubqU/ZGjMHi71bBdoDiqXZ9NxwAx7M=; b=L/pLgDVuvKxiHxMPZPy/CN2z/DdP+WDHQQWLyMdG+GDQm2Hs1iJNJXAoYW DtdJtGssx4C3KjStHrX1+1TKxUsIc9bK208qbI8T+qlnrQXR7qZNAt7dGIAH NZXgVvN0xl; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Thu, 04 Jun 2009 11:06:31 -0700 Cc: opsawg@ietf.org, Sam Hartman , ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 18:05:44 -0000 Adopting this document as a BCP would be a serious mistake, and I hope it will be strongly opposed. There is absolutely no evidence that following the dictates of this document will improve the quality of the IETF's work, and we certainly know it won't improve the timeliness. There is no evidence that ignoring it will harm the Internet. I don't see that OPSAWG has any business imposing requirements on work done by other WGs in other Areas. There are already an adequate number of obstacles to getting work done. The last thing we need is another required "considerations" section, or another set of excuses for ADs from one Area to block documents from other Areas. From dromasca@avaya.com Thu Jun 4 11:11:07 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855833A70AA for ; Thu, 4 Jun 2009 11:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 4VF0CNaE-rsB for ; Thu, 4 Jun 2009 11:11:00 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A9C143A6F2B for ; Thu, 4 Jun 2009 11:11:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,306,1241409600"; d="scan'208";a="172954950" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jun 2009 14:11:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 04 Jun 2009 14:11:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 20:10:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP Thread-Index: AcnlH2LklOl1RYMmTJO2J5CKUe83VAAIGA9Q From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] FW: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 18:11:07 -0000 =20 -----Original Message----- From: Eliot Lear [mailto:lear@cisco.com]=20 Sent: Thursday, June 04, 2009 5:19 PM To: Romascanu, Dan (Dan) Cc: IETF@ietf.org Subject: Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP [this one more publicly] Dan, Based on the goals you set out below, I would argue that the document is too long. I would recommend sticking with principles and calling out a few examples. I think this is done reasonably well in Section 2, and less so elsewhere. I would also suggest that you scope the document, because what you write below wasn't clear to me on first read. Eliot On 6/4/09 11:16 AM, Romascanu, Dan (Dan) wrote: > Sam, > > Thank you for your review and opinions. > > I would like to remind you and let many people that are not aware=20 > about the history of the document know one fact that may be important. > This document is an outcome of the discussions hold at the IESG=20 > retreat in May 2006. I was then the 'fresh' AD bringing this issue to=20 > the IESG table, we discussed approaches on dealing with management in=20 > the IETF and the need for a different approach of looking at=20 > management than the 'write a MIB' which was the rule in the IETF WGs=20 > until then. I took the action item to 'write a draft' on this issue -=20 > which then developped in this piece of work chartered in the OPSAWG. > > > ... > > =20 >> This is a concern that the document does not have broad enough=20 >> consensus to be a BCP. I believe that significant areas of the IETF=20 >> do not view management interoperability as a goal--much less a=20 >> guiding principle of management. I've been involved in discussions=20 >> in the Kerberos working group where we explicitly discussed this and=20 >> came to the conclusion that management interoperability was not=20 >> something anyone in the room was going to work on. We did work on an >> information model which covers aspects where people believed some=20 >> degree of management interoperability would be desirable. It does=20 >> not cover monitoring, faults, or the like--only provisioning of the=20 >> database. >> >> >> Similarly, I'm quite certain that most web server vendors, ATOM=20 >> implementors, etc do not want management interoperability. I=20 >> understand that ISP operators very much do want management=20 >> interoperability. I think that we have a significant conflict here=20 >> and I think that we cannot approve such a BCP without addressing that >> conflict. One possible resolution would be to find an subsection of=20 >> the IETF that actually agrees with these guidelines and scoping the=20 >> BCP. >> >> Similarly, it has been my experience that the desire to standardize=20 >> information model semantics is not universal across the IETF. >> =20 > I believe that the document recognizes the variance in approaches for=20 > the different areas, protocols, and working groups in the IETF and for > this reason rightly avoids making a prescription or imposing a fixed=20 > solution or format in dealing with operational considerations and=20 > manageability aspects of the IETF protocols. I think that it does make > however the point that operational deployment and manageability=20 > aspects need to be taken into considerations for any new IETF work.=20 > The awareness of these issue should exist in any work the IETF engages > with, after all we develop technologies and protocols to be deployed=20 > and operated in the real life Internet, not abstract mathematical=20 > models. It is fine if a WG decides that its protocol needs not=20 > interoperable management or no standardized data model, but this=20 > should be the result of discussions and decisions, not of mission. > > Dan > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > =20 From randy_presuhn@mindspring.com Thu Jun 4 12:00:46 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546103A70E9; Thu, 4 Jun 2009 12:00:46 -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 gMFnUixUc0n1; Thu, 4 Jun 2009 12:00:45 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id AD52C3A70D5; Thu, 4 Jun 2009 12:00:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=gDo++2j7+qHTdIfp4rDFdzVx+2VQBjp6wuQDNYEz6Gj5IWc3QkbSMCV2pSnClDLw; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.196] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MCIAz-0008Ht-FO; Thu, 04 Jun 2009 15:00:33 -0400 Message-ID: <004a01c9e546$bb78d720$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , References: <20090519133936.DC6B63A6AC0@core3.amsl.com> <4A27667E.9020409@cisco.com> Date: Thu, 4 Jun 2009 12:00:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69685a61ba34b0332f0afaa521864778e621350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.196 Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:00:46 -0000 Hi - > From: "Eliot Lear" > To: "Sam Hartman" > Cc: ; > Sent: Wednesday, June 03, 2009 11:15 PM > Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP ... > Also, I agree with you that interoperability is not the first and > primary goal. Clearly, and I hope Dave and others will agree, the > primary goal is the ability to roll out new useful functions and > services in a way in which they can be managed in a scalable manner, > where one has understood the network impact (or total cost, if you will) > for that service. And Section 2 provides a really nice illustration of > that, with regard to what happened at Berkeley. Unfortunately, I think the IETF has only adopted the first sentence of this paragraph. The hard work (and it is hard work) to build interoperable *management* seems to have largely been abandoned in the IETF. I think the state of the netconf work attests to the shift to just shoveling around vendor-specific blobs, rather than management information. > I have another problem with 3.2: I think the SMI and other > registry-based forms of structured data may be overrated in some cases. They're not a panacea. The SMI has weaknesses that can make models cumbersome. I haven't seen a data representation or way of representing data semantics that was ideal for all purposes, and I doubt I ever will. Unfortunately, this recognition that nothing is perfect seems to have led the IETF dangerously close to "anything goes." One would hope that this document would help WGs avoid the worst excesses. > Sometimes what is being managed is very simple data, through a central > service. One has to question who the consumer of the data is prior to > determining how one encodes that data, or even what data is truly > necessary. Consider the case of an application that is simply calling > home to determine if there are patches. How much structured data does > that service need? If there will ever be more than one patch, if there are dependencies between patches, if there is every the need to revert, if there are hardware or model dependencies.... It's really easy to over-simplify, and end up needing a whole bundle of band-aids as the system's needs evolve (or are recognized). ... > What I would suggest is that some additional context is necessary > throughout the document to indicate really who we are talking to. Are > we limiting our role to router management? What happened to the toaster > with an SNMP stack? Would we use SNMP today for that toaster? Who > would manage it? Well, let's put it in a more serious context and swap > toaster for major appliance like air conditioner or refrigerator or PDU. The IETF management discussions have increasingly limited themselves to what it takes to manage a few types of network gear. It seems to me that the IETF abandoned any hope of doing system management, or even management of multi-vendor systems, a long time ago. This may be a bug, this may be a feature. The thrust of this document seems to me to be a recognition of this state of affairs, and that consequently, if we're going to let a thousand vendor- or application-specific flowers bloom, a little advice to help avoid some of the mistakes of the past would be helpful. Consequently, I think having this document is a good thing. The advice it gives reflects the current fragmented state of affairs with respect to management information, and would be useful to folks trying to do a good job in this environment. I can support this as an informational document. I could somewhat reluctantly go along with making it BCP - our experience with that catch-all designation makes it clear that "Best" only means "what we could more-or-less agree on" and "Current" can mean "we really hope something better will come along, but aren't going to hold our breath." Randy From hartmans@mit.edu Thu Jun 4 12:47:11 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5353A6CE3; Thu, 4 Jun 2009 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, RDNS_DYNAMIC=0.1] 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 0PXm0Wkx7czx; Thu, 4 Jun 2009 12:47:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-18-111-18-188.dyn.mit.edu [18.111.18.188]) by core3.amsl.com (Postfix) with ESMTP id F1DAC3A6AB3; Thu, 4 Jun 2009 12:47:10 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AE6C34159; Thu, 4 Jun 2009 15:47:02 -0400 (EDT) To: Eric Rosen References: <20090519133936.DC6B63A6AC0@core3.amsl.com> <15968.1244138731@erosen-linux> From: Sam Hartman Date: Thu, 04 Jun 2009 15:47:02 -0400 In-Reply-To: <15968.1244138731@erosen-linux> (Eric Rosen's message of "Thu\, 04 Jun 2009 14\:05\:31 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org, Sam Hartman , ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:47:11 -0000 >>>>> "Eric" == Eric Rosen writes: Eric> I don't see that OPSAWG has any business imposing Eric> requirements on work done by other WGs in other Areas. Obviously I agree with this statement. However I do believe that the ops area can propose and build consensus on requirements that we all agree to follow. I think this document may be a starting point in such a discussion. I think Eric and I probably both agree it should not be the final word. From erosen@cisco.com Thu Jun 4 13:17:17 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC5228C209; Thu, 4 Jun 2009 13:17: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 fj0cAIFJBtI4; Thu, 4 Jun 2009 13:17:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D49313A6CE2; Thu, 4 Jun 2009 13:17:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,307,1241395200"; d="scan'208";a="167357350" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 04 Jun 2009 20:17:18 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n54KHIsu030177; Thu, 4 Jun 2009 16:17:18 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n54KHIBB011760; Thu, 4 Jun 2009 20:17:18 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n54KHHso017186; Thu, 4 Jun 2009 16:17:18 -0400 To: "Joel M. Halpern" In-reply-to: Your message of Thu, 04 Jun 2009 15:54:07 -0400. <4A28265F.3040303@joelhalpern.com> Date: Thu, 04 Jun 2009 16:17:17 -0400 Message-ID: <17185.1244146637@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1504; t=1244146638; x=1245010638; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-ietf-opsawg-oper ations-and-management(Guidelines=20for=20Considering=20Opera tions=20and=20Management=20of=20NewProtocols=20and=20Protoco l=20Extensions)=20to=20BCP=20 |Sender:=20 |To:=20=22Joel=20M.=20Halpern=22=20; bh=L0Hru3mKqqd3kttDVps9wdyTGj+m5XX+Qo/IJjFR5YY=; b=sfnEUX7q8rurq6UrCKyd4NKCSJX8ZPH2bun4KCfrDHoBqdXdnk5e39c2Bl 0KV8mL4wfyzR89RA1x0rnUdQV43P/1AEuo0k+ZKsYoO5czLp6iDLdE7XgpJj AD4aC5SEGo; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Eric Rosen , Sam Hartman , opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:17:17 -0000 > This does not mean we have to simply accept what they (OPS) say. But it > does mean we should give it a fair review, looking at the details, > rather than objecting on principle. This is absolute nonsense. Most of the people actually doing work in the various areas do not have the time, interest, or expertise to do a detailed review of an OPS document. However, these are the people who are in the best position to determine whether "OAM Considerations" would help or hinder the work that they do. If we are going to talk about adding new hoops for folks to jump through, we should first discuss whether any such hoops are necessary. We should not start the discussion by looking at the details of the particular proposed hoops. > the OPS area has as much right to propose their requirements as any other > area (Transport Congestion, Security, ...) has. And generally, the > community has listened to such requests and gone along with them. Generally, the community (i.e., the folks doing the work in the various areas) has never even heard about these proposed requirements until after a BCP appears, at which time they are told that the BCP "has community consensus". Perhaps you're familiar with Douglas Adams' "The Hitchhiker's Guide to the Galaxy". To paraphrase, "but the plan for the destruction of earth was clearly posted in the planning department on alpha centauri, it's not our fault you didn't see it". From andy@netconfcentral.com Thu Jun 4 13:45:30 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F773A6D37 for ; Thu, 4 Jun 2009 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 82wnPqikZWWS for ; Thu, 4 Jun 2009 13:45:30 -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 660D93A6CBD for ; Thu, 4 Jun 2009 13:45:30 -0700 (PDT) Received: (qmail 15953 invoked from network); 4 Jun 2009 20:38:53 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.121.106.126 with plain) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 4 Jun 2009 20:38:52 -0000 X-YMail-OSG: tyf8N3gVM1mb5pGNpSgDHiPcWufVDALU5wB28hbrfts1G3Se7_rGL70ew4cBPlcfoKUz93iIKQLwIY2Cr.eYvxy6qZdiJlcuBDVQU9k58XO12v5NFt6C_.NtIfaTbH2Xn9PyXukjqOPh15.j1WqCmqnYl4zSOWnf58JHSYbmWrPNH3IKt31cfClrHS0C3CukAOv.9qfNsgIfBpRdVNTScmQBJQyP9Z7j4WmFXlYiM_UWQ4XdlLVMT8q.PTEHzHUz3jg2DS6Ogp5YoH.c X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2830C4.2020204@netconfcentral.com> Date: Thu, 04 Jun 2009 13:38:28 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20090519133936.DC6B63A6AC0@core3.amsl.com> <15968.1244138731@erosen-linux> <4A28265F.3040303@joelhalpern.com> In-Reply-To: <4A28265F.3040303@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Rosen , Sam Hartman , opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:45:30 -0000 Joel M. Halpern wrote: > To put it differently, the OPS area has as much right to propose their > requirements as any other area (Transport Congestion, Security, ...) > has. And generally, the community has listened to such requests and > gone along with them. > > Yes, we have produced a bit of a problem that our initial standards now > have a quality bar comparable with completed work. But we shouldn't > suddenly pick on OPS for that. If we are going to address that problem, > it ought to be in a coherent fashion that discusses how we deal with all > the legitimate requirements, including the fact that stuff has to be > operable. > I agree, and I also agree with Randy about the lack of standardized NETCONF content. It is a clear indication that the vendors do not want any standardized configuration content. Every time 'content' has come up for charter consideration, the consensus has been to work on something else instead. But the NETCONF/YANG pieces are coming together, and it will allow WGs much more power and flexibility than SNMP/SMIv2 to define management interfaces which fit better with the native CLI than anything the IETF has had before. That is about as far as OPS-NM area can go. If a protocol WG do not want to define a standard configuration interface, then it does not matter how well SNMP or NETCONF supports this sort of work. (One might question whether using the same NM standardization methodology for 20 years and achieving consistently pathetic results means the methodology itself needs to be changed, not just the technology.) > This does not mean we have to simply accept what they (OSP) say. But it > does mean we should give it a fair review, looking at the details, > rather than objecting on principle. > > Yours, > Joel M. Halpern > Andy From hartmans@mit.edu Thu Jun 4 13:54:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E1083A6774; Thu, 4 Jun 2009 13:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, RDNS_DYNAMIC=0.1] 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 8c7XQgOKVrpa; Thu, 4 Jun 2009 13:54:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-18-111-18-188.dyn.mit.edu [18.111.18.188]) by core3.amsl.com (Postfix) with ESMTP id 1FDB53A68AD; Thu, 4 Jun 2009 13:54:08 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5EDB64141; Thu, 4 Jun 2009 16:54:06 -0400 (EDT) To: erosen@cisco.com References: <17185.1244146637@erosen-linux> From: Sam Hartman Date: Thu, 04 Jun 2009 16:54:06 -0400 In-Reply-To: <17185.1244146637@erosen-linux> (Eric Rosen's message of "Thu\, 04 Jun 2009 16\:17\:17 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org, "Joel M. Halpern" , Sam Hartman , ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:54:12 -0000 >>>>> "Eric" == Eric Rosen writes: Eric> If we are going to talk about adding new hoops for folks to Eric> jump through, we should first discuss whether any such hoops Eric> are necessary. We should not start the discussion by Eric> looking at the details of the particular proposed hoops. Agreed. I think that if we don't have agreement with the goals/high-level of this type of proposal, it's completely reasonable to block review of details until that reaches agreement. From jmh@joelhalpern.com Thu Jun 4 12:54:14 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53473A6C5E; Thu, 4 Jun 2009 12:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 w5u6FL5ImVAw; Thu, 4 Jun 2009 12:54:14 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2DF0A3A6C13; Thu, 4 Jun 2009 12:54:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EF875430327; Thu, 4 Jun 2009 12:54:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C1F7F430337; Thu, 4 Jun 2009 12:54:15 -0700 (PDT) Message-ID: <4A28265F.3040303@joelhalpern.com> Date: Thu, 04 Jun 2009 15:54:07 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Hartman References: <20090519133936.DC6B63A6AC0@core3.amsl.com> <15968.1244138731@erosen-linux> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 04 Jun 2009 14:23:46 -0700 Cc: Eric Rosen , opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:54:15 -0000 To put it differently, the OPS area has as much right to propose their requirements as any other area (Transport Congestion, Security, ...) has. And generally, the community has listened to such requests and gone along with them. Yes, we have produced a bit of a problem that our initial standards now have a quality bar comparable with completed work. But we shouldn't suddenly pick on OPS for that. If we are going to address that problem, it ought to be in a coherent fashion that discusses how we deal with all the legitimate requirements, including the fact that stuff has to be operable. This does not mean we have to simply accept what they (OSP) say. But it does mean we should give it a fair review, looking at the details, rather than objecting on principle. Yours, Joel M. Halpern Sam Hartman wrote: >>>>>> "Eric" == Eric Rosen writes: > > Eric> I don't see that OPSAWG has any business imposing > Eric> requirements on work done by other WGs in other Areas. > > Obviously I agree with this statement. However I do believe that the > ops area can propose and build consensus on requirements that we all > agree to follow. I think this document may be a starting point in > such a discussion. I think Eric and I probably both agree it should > not be the final word. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From j.schoenwaelder@jacobs-university.de Fri Jun 5 11:44:56 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9393A6B58; Fri, 5 Jun 2009 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 Epso7TEeBNb6; Fri, 5 Jun 2009 11:44: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 3EAC13A69B8; Fri, 5 Jun 2009 11:44:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A674C00FB; Fri, 5 Jun 2009 20:44:58 +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 rWWksUCldc+6; Fri, 5 Jun 2009 20:44: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 7320EC00EB; Fri, 5 Jun 2009 20:44:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 70992B2DC48; Fri, 5 Jun 2009 20:44:55 +0200 (CEST) Date: Fri, 5 Jun 2009 20:44:55 +0200 From: Juergen Schoenwaelder To: Eric Rosen Message-ID: <20090605184455.GB22529@elstar.local> Mail-Followup-To: Eric Rosen , "Joel M. Halpern" , Sam Hartman , "opsawg@ietf.org" , "ietf@ietf.org" References: <4A28265F.3040303@joelhalpern.com> <17185.1244146637@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17185.1244146637@erosen-linux> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" , "Joel M. Halpern" , Sam Hartman , "ietf@ietf.org" Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 18:44:56 -0000 On Thu, Jun 04, 2009 at 10:17:17PM +0200, Eric Rosen wrote: > Generally, the community (i.e., the folks doing the work in the various > areas) has never even heard about these proposed requirements until after a > BCP appears, at which time they are told that the BCP "has community > consensus". Perhaps you're familiar with Douglas Adams' "The Hitchhiker's > Guide to the Galaxy". To paraphrase, "but the plan for the destruction of > earth was clearly posted in the planning department on alpha centauri, it's > not our fault you didn't see it". There is a defined IETF review process and we just go through it and from what I can tell the process works in making people comment on the draft that was proposed to become a BCP. While comments on the content of the draft are fine, I find comments on the process pretty much out of scope. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sisyphus@dial.pipex.com Fri Jun 5 03:56:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D483A6846; Fri, 5 Jun 2009 03:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 ywKXLPonN+wZ; Fri, 5 Jun 2009 03:56:49 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 92EEF3A6829; Fri, 5 Jun 2009 03:56:48 -0700 (PDT) X-Trace: 110239385/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.217/None/sisyphus@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.217 X-IP-MAIL-FROM: sisyphus@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAByXKEo+vGTZ/2dsb2JhbABEgmVSizXAOwiEAgU X-IronPort-AV: E=Sophos;i="4.41,310,1241391600"; d="scan'208";a="110239385" X-IP-Direction: IN Received: from 1cust217.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.217]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 11:56:48 +0100 Message-ID: <003801c9e5c3$cb0d4e00$0601a8c0@allison> From: "Tom.Petch" To: "Adrian Farrel" , References: <20090519133936.DC6B63A6AC0@core3.amsl.com><4A27667E.9020409@cisco.com> <65560109893A4E21A127CA9CB729841B@your029b8cecfe> Date: Fri, 5 Jun 2009 09:33:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 X-Mailman-Approved-At: Fri, 05 Jun 2009 12:28:13 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management(Guidelinesfor Considering Operations and Management of NewProtocols and ProtocolExtensions) to BCP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Tom.Petch" List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 10:56:49 -0000 ----- Original Message ----- From: "Adrian Farrel" To: Cc: Sent: Thursday, June 04, 2009 11:58 AM > In the discussion of IETF consensus of this document and its position as a > BCP or otherwise, can I throw into the melting pot > draft-ietf-pce-manageability-requirements-06.txt Yes, a clear concise set of steps to follow when writing an I-D. The other comment I would make on the I-D under Last Call is on the first sentence of the abstract, to whit, " New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. " True, but not, I think, addressed by this document. There is plenty in this I-D for the I-D editor but little for the protocol designer. The latter might benefit from advice on how to structure elements of the PDUs and the interchange of PDUs; it may be difficult to know whether or not a network is functioning if there is no keepalive. (A comparable discussion surfaced recently on apps-discuss over the best way to encode lengths). I appreciate that this I-D does not set out to give such advice but think that someone reading the abstract might expect it to. Tom Petch > This particular I-D was developed within the PCE working group to apply only > in that working group. It covers similar topics, but is more focused on > ensuring that the protocols that are developed in PCE are manageable. > > The I-D has rough WG consensus (or did at the time I stopped being chair a > few months ago), but is not mandatory to implement within the WG. > > It is my opinion that those PCE I-Ds that have taken the draft on board have > produced better solutions that will be more successfully implemented and > deployed. > > Cheers, > Adrian From miguel.a.garcia@ericsson.com Thu Jun 4 23:33:04 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3843A6872; Thu, 4 Jun 2009 23:33:04 -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 OW-ckd-r3xwe; Thu, 4 Jun 2009 23:33:02 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A1DB03A672F; Thu, 4 Jun 2009 23:33:01 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-99-4a28bc1e2728 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2E.92.08287.E1CB82A4; Fri, 5 Jun 2009 08:33:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 08:32:47 +0200 Received: from [159.107.24.241] ([159.107.24.241]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 08:32:46 +0200 Message-ID: <4A28BC0E.4010803@ericsson.com> Date: Fri, 05 Jun 2009 08:32:46 +0200 From: "Miguel A. Garcia" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David Harrington References: <01c401c9e523$9e37c180$0600a8c0@china.huawei.com> In-Reply-To: <01c401c9e523$9e37c180$0600a8c0@china.huawei.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030801040003010509080100" X-OriginalArrivalTime: 05 Jun 2009 06:32:46.0848 (UTC) FILETIME=[709E2000:01C9E5A7] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 05 Jun 2009 12:28:34 -0700 Cc: opsawg@ietf.org, gen-art@ietf.org, opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] FW: Gen-ART review ofdraft-ietf-opsawg-operations-and-management-07.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 06:33:04 -0000 This is a cryptographically signed message in MIME format. --------------ms030801040003010509080100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi David: I am fine with your comments. /Miguel David Harrington wrote: > Hi, > > Thank you for the review. > comments inline. > >> -----Original Message----- >> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >> Sent: Monday, June 01, 2009 4:36 PM >> To: dharrington@huawei.com; Romascanu, Dan (Dan) >> Cc: opsawg-chairs@tools.ietf.org; General Area Review Team >> Subject: Gen-ART review of >> draft-ietf-opsawg-operations-and-management-07.txt >> >> I have been selected as the General Area Review Team >> (Gen-ART) reviewer >> for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please resolve these comments along with any other Last Call > comments >> you may receive. >> >> Document: draft-ietf-opsawg-operations-and-management-07.txt >> Reviewer: Miguel Garcia Review Date: >> 01-June-2009 IETF LC End Date: 02-June-2009 >> >> Summary: The document is ready for publication as a BCP. >> >> Major issues: none >> >> Minor issues: none >> >> Nits/editorial comments: A few nits, if you have a chance to bring > to >> the document. >> >> - Spelling errors: >> Page 5: s/Informatiion/Information >> Page 9: capitalize "it" in "it is extremely important..." > fixed. > >> - Expand acronyms at first occurrence and add a reference to them > (if >> they are documents). This includes: SNMP, SYSLOG, COPS, XML, RADIUS, >> DIAMETER, NETCONF, IPFIX, DMTF, TMF, RMON, and NMS. >> >> - Although a reference exist later in the text, I would add a >> reference >> to RFC 3444 in Section 1.6 in relation with bullet points 1 and 2. > done > >> - Page 10, Section 2.4. The text talks about a "router alert". I > guess >> you should add a reference to the relevant document that describes >> "Router alert", presumably RFC 2113 and RFC 2711 > done >> - In Section 3.6, page 21, second and third paragraphs talk about >> existing working groups (BMWG and IPPM) and their deliverables (some >> "metris", referenced by name not by reference). If we >> consider a reader >> of this document some 5 years from now, at that time perhaps those > WGs >> do not exist any longer, and it would be hard to trace the >> deliverables >> that this draft is trying to consider. I think it is useless to have > a >> reference by name, because it will be hard to find it when the RFC > is >> published. I think the draft should refer a document, I-D or >> RFC, with a >> proper reference. If this cannot be done, the text is mostly > useless. > > I modified the text to say > "The IETF, via the Benchmarking Methodology WG (BMWG), has defined > recommendations..." and added "Search for "benchmark" in the RFC > search tool." > > and > "The IETF, via the IP Performance Monitoring (IPPM) WG, has developed > a set of standard metrics that can be applied to the quality, > performance, and reliability of Internet data delivery services. These > metrics are designed such that they can be performed by network > operators, end users, or independent testing groups. The existing > metrics might be applicable to the new protocol. Search for "metric" > in the RFC search tool." > >> - Comment. Section 4.3 discusses the placement of the Operations and >> Manageability Considerations Section. I think the Instructions to > RFC >> Authors, http://www.rfc-editor.org/howtopub.html should be updated > to >> reflect this draft, especially in the section that discusses the > names >> and titles of sections in an RFC. I know this effort is not >> part of the >> author's role, but it should be done by someone at some point in > time. > > That discussion is (deliberately) above my pay grade. ;-) > >> /Miguel >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain --------------ms030801040003010509080100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRQjCC BEAwggMooAMCAQICED2uakOK1C7f6EwHN7p8V44wDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0w ODA4MDcwNjQzNTNaFw0xMTA4MDcwNjQzNDlaMHcxETAPBgNVBAoMCEVyaWNzc29uMSMwIQYD VQQDDBpNaWd1ZWwgQW5nZWwgR2FyY2lhIE1hcnRpbjEQMA4GA1UEBRMHZW1pbGdhbjErMCkG CSqGSIb3DQEJARYcbWlndWVsLmEuZ2FyY2lhQGVyaWNzc29uLmNvbTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAk9x/j2raY36OtyoPkiYlEIAJ3OuzXDBZ6dat5ErHbV+RjVTD753O jnPzu2hdEmEfpsARg5N//5wQFUg+9qmpT9EV20yoY3lLJvdqlABRUianc9mZfP8MO+tFCo7H FJsTyEWmK27whQuiAEHpr35C4Ui4uhpHNj5X4oF9rYGrk6cCAwEAAaOCAYgwggGEMIHABgNV HR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL0VyaWNzc29u TkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRlbGlhLmNvbS9jbj1F cmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nvbj9jZXJ0aWZpY2F0 ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHG1pZ3VlbC5hLmdhcmNp YUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYjaHR0 cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFJXcs0YFcSsz1xdJ r1nqqUArLYomMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQE AwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAFM7tRSbj7TpHs1yrgp91tfjJoZSlMlmO/tjqJF+r +P8e9hedUgnpacbqsPSdUDD6hgv5k7pfkzSHomzL/y7cj0hTDUp9rs7Et/Xp6qHg2lN9yknt jozc5iw9ert1MVbawWt7x5qEgHI3E+7xg2GRSd0nCFcK74wqS9kS86DmWrkKWgHJnPw2clrl 9+rc7VYrBhJYlMjQy6SiJvMwuA4z0iNQVxOEBuU4aL7p2yAvUSuCpoL24/DaKJKjbJDm8xii aKFHmpdVjAbii61WkltBHEletJZM1ZNXhCFGuixw7cw/GAZE4aV7cA/WSaO9Lwc/DkC4xs77 6FBNHLpxksn0jzCCBEAwggMooAMCAQICED2uakOK1C7f6EwHN7p8V44wDQYJKoZIhvcNAQEF BQAwOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EwMTAeFw0wODA4MDcwNjQzNTNaFw0xMTA4MDcwNjQzNDlaMHcxETAPBgNVBAoMCEVy aWNzc29uMSMwIQYDVQQDDBpNaWd1ZWwgQW5nZWwgR2FyY2lhIE1hcnRpbjEQMA4GA1UEBRMH ZW1pbGdhbjErMCkGCSqGSIb3DQEJARYcbWlndWVsLmEuZ2FyY2lhQGVyaWNzc29uLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAk9x/j2raY36OtyoPkiYlEIAJ3OuzXDBZ6dat 5ErHbV+RjVTD753OjnPzu2hdEmEfpsARg5N//5wQFUg+9qmpT9EV20yoY3lLJvdqlABRUian c9mZfP8MO+tFCo7HFJsTyEWmK27whQuiAEHpr35C4Ui4uhpHNj5X4oF9rYGrk6cCAwEAAaOC AYgwggGEMIHABgNVHR8EgbgwgbUwgbKgga+ggayGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEu Y29tL0VyaWNzc29uTkxJbmRpdmlkdWFsQ0EwMS5jcmyGcWxkYXA6Ly9sZGFwLnRydXN0LnRl bGlhLmNvbS9jbj1Fcmljc3NvbiUyME5MJTIwSW5kaXZpZHVhbCUyMENBMDEsbz1Fcmljc3Nv bj9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlMCcGA1UdEQQgMB6BHG1p Z3VlbC5hLmdhcmNpYUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggr BgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYE FJXcs0YFcSsz1xdJr1nqqUArLYomMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCb MA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAFM7tRSbj7TpHs1yrgp91tfjJ oZSlMlmO/tjqJF+r+P8e9hedUgnpacbqsPSdUDD6hgv5k7pfkzSHomzL/y7cj0hTDUp9rs7E t/Xp6qHg2lN9ykntjozc5iw9ert1MVbawWt7x5qEgHI3E+7xg2GRSd0nCFcK74wqS9kS86Dm WrkKWgHJnPw2clrl9+rc7VYrBhJYlMjQy6SiJvMwuA4z0iNQVxOEBuU4aL7p2yAvUSuCpoL2 4/DaKJKjbJDm8xiiaKFHmpdVjAbii61WkltBHEletJZM1ZNXhCFGuixw7cw/GAZE4aV7cA/W SaO9Lwc/DkC4xs776FBNHLpxksn0jzCCBEUwggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+Mw DQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3JvdXAxJjAkBgNVBAMM HVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2MTAwNjEwMDA1M1oXDTE2MTAw MjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALYQd+Q1HuuH xDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLnfub9LBc7dQpR Hjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT39h79brH dRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXRlobv 0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB /wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBz Oi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFw Oi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290 JTIwQ0ElMjB2MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxp c3Q/YmFzZTAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCb MB8GA1UdIwQYMBaAFEXb8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2 AEoqQz+M3Ra9alkpn/YnwhXIv6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq 3r+x/GK3in/mik8i/PK2/q8HutzYFSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9s G2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwr MUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpv Cu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIR AJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNBIFNlY3Vy aXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDYxMDMxMjA0MjI3 WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBHcm91cDEmMCQGA1UE AwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdWPMLHDjzh w5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/jel5 9WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjgh XYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMB AAGjggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQU Rdvwj7gaYqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9 BgkqhkiG9w0FBgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhLmNvbTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50 cnVzdC50ZWxpYS5jb20wcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0 eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0Ff U2VjdXJpdHlfMjA0OF92My5DUkwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IB AQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7 GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ix CTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTPBH/1poLccsUxsKgrQ23JC9LWCRb8 cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+npjwPbedMPUZkDYCkd3LSxj8c 3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5GtDYPMYICZjCCAmICAQEw TTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVh bCBDQTAxAhA9rmpDitQu3+hMBze6fFeOMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYwNTA2MzI0NlowIwYJKoZIhvcNAQkE MRYEFA/VCSu7wcy+cIi/wAtG1DJui5X0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNz c29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQPa5qQ4rULt/oTAc3unxXjjBeBgsqhkiG9w0BCRAC CzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EwMQIQPa5qQ4rULt/oTAc3unxXjjANBgkqhkiG9w0BAQEFAASBgCwv53FshWst vOK71iL6Zlqj+8CBMsH9FmlsXz5dxfR6KkfxVzk0BwSm0qTQCBoIlCVRk2UDDalLYWBdEybA BbZmZ7ySPMhbV2S9p436cgd5AXdh1eXvi8PFmp+iFFbSlVq38s4qO5u+xR5rfAw65EMA7QXn izvCGosZISHMWQb2AAAAAAAA --------------ms030801040003010509080100-- From sob@harvard.edu Wed Jun 10 05:04:29 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92F03A6B59 for ; Wed, 10 Jun 2009 05:04:29 -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 fOhF9QgYZ8BJ for ; Wed, 10 Jun 2009 05:04:29 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 127F43A6AF4 for ; Wed, 10 Jun 2009 05:04:29 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id B64C71826A4C; Wed, 10 Jun 2009 08:04:34 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090610120434.B64C71826A4C@newdev.eecs.harvard.edu> Date: Wed, 10 Jun 2009 08:04:34 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] draft-andersson-mpls-tp-oam-def-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:04:30 -0000 We had a presentation of this ID at a WG meeting a while back. At the time there seemed to be some interest in publishing a RFC that would be a help to people trying to understand just what the concept of OAM means in the IETF and other contexts - since there is so much confusion and because it can be hard to hold a conversation with somone coming from a different context. this is a call to see if you-all think that this ID (draft-andersson-mpls-tp-oam-def-01.txt) whould be adopted by the opsawg as a work item. Please comment on the list in the next two weeks (i.e., before June 25th) Thanks Scott From dromasca@avaya.com Tue Jun 16 04:26:23 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AF43A6B22 for ; Tue, 16 Jun 2009 04:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 Y0JnmNiGowh0 for ; Tue, 16 Jun 2009 04:26:22 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8E8C93A69C2 for ; Tue, 16 Jun 2009 04:26:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243828800"; d="scan'208";a="174058755" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Jun 2009 07:25:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Jun 2009 07:25:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 13:25:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnudTEF2BuejjucSsWXt/SeycFI1w== From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 11:26:24 -0000 Please find below the AD review for draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt. I believe that this document is mature enough to be sent to IETF Last Call. Unless there are any last minute comments I plan to send it to IETF Last Call by tomorrow.=20 The requirements below are dived into Technical and Editorial. Please consider them together with the other Last Call comments. T1. I am not sure that I understand requirement R2 in Section 3. It does not look like it imposes any requirement for the mapping. It is sufficient I think that we dully state that version SMIv2 is the version that is supported, and that any SMIv1 MIB module should be first translated into SMIv2. Maybe this is actually the intention, but this is not a requirement on the mapping.=20 E1. Running idnits results in the following warning:=20 =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." E2. According to RFC 5377 he Section 4 'code' will need to include a full version of the full BSD license or a statement agreed by the IETF Trust. The exact formulation of the statement is still in discussions, please follow the latest instructions available at http://trustee.ietf.org/license-info/ E3. Section 1 - s/legacy MIBs/legacy MIB modules/ E4. same - what does 'with attendant improvements' mean?=20 E5. same - it looks to me like some paragraphs are redundant and this section can be shortened. For example the paragraphs starting with 'The objective of this memo ...' and 'Having such a standard mapping ...' do not seem to bring any new information, they just say what was already said earlier in the same section. E6. same - 'The goal of fidelity ...' I am not sure that 'fidelity' is the right term - maybe 'consistency' or 'accurate translation' or 'accurate mapping' E7. Section 3, R6 - it is not clear to me what 'the most direct' means E8. same, R7 - again 'the most direct'. Also, I am not sure that saying 'no comments included' is a requirement. In many cases comments are useful and not superfluous 'decoration' E9. Section 5 - It would be good to include the exact reference to W3C XSD in the text E10. Section 5.1 - 'faithful' does not sound like the right term E11. Section 5.4 - although trivial for people familiar with SMI it may be helpful for some to explain why only IPv4 addresses are described in the document E12. Section 5.5 - It would be better rather then use a tutorial as a reference to refer to the standard directly for ASN.1 / BER Encoding. Reference [4] in RFC 2578 seems to be the right one.=20 Thanks and Regards, Dan From RNATALE@mitre.org Tue Jun 16 11:14:50 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6F13A6BDA for ; Tue, 16 Jun 2009 11:14:50 -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 bOi7OLaLPvIp for ; Tue, 16 Jun 2009 11:14:49 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D70923A6A91 for ; Tue, 16 Jun 2009 11:14:48 -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 n5GIEtpR006468 for ; Tue, 16 Jun 2009 14:14:55 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n5GIEtee006455; Tue, 16 Jun 2009 14:14:55 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 16 Jun 2009 14:14:54 -0400 From: "Natale, Bob" To: "Romascanu, Dan (Dan)" Date: Tue, 16 Jun 2009 14:14:54 -0400 Thread-Topic: AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnudTEF2BuejjucSsWXt/SeycFI1wALvl8g Message-ID: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:14:50 -0000 Hi Dan, Thanks for the comments and for moving the IETF process forward. Concerning your comments: T1: Yes, that is the intent of the R2: An SMIv1 MIB module must be converte= d to SMIv2 (insofar as datatypes are concerned) in accordance with RFC 3584= *prior to mapping to XSD as specified in this I-D* (or eventual RFC). Per= haps I should make that last part explicit in the wording of R2...? E1: I examined the idnits warning carefully at the time and decided that th= e answer to its question "Should you add the disclaimer?" was no, because i= t did not seem necessary per the terms of the warning. Do you feel that wa= s the wrong conclusion? E2: Reading RFC 5377 gives me a headache, literally, and quickly. By time = I got through the end of its Sec. 4.3, it seemed to me that it was saying t= hat the IETF Trustees "should define" some kind of text to include for XSDs= and such. So, I then reviewed the text of http://trustee.ietf.org/docs/IE= TF-Trust-License-Policy.pdf (much bigger headache now) and it seems to me t= hat it says that the BSD license grant for the XSD "code" is implicitly gra= nted by virtue of the "Copyright Notice" in the I-D (RFC) -- and that autho= rs would have to do something concrete (insert other text) to explicitly ap= ply some other license grant (or usage restrictions). Do you read that pol= icy differently? E3: Will apply your change. E4: "attendant improvements" means "expected corresponding improvements fro= m more unified management" (or words to that effect)...the predicate here i= s that technology that helps to eliminate the need for discrete operations = across multiple management layers/technologies to complete a task is likely= to also result in overall faster operations and overall fewer errors in op= erations. E5: You are probably right. I will take a look at how to reduce the text w= /o loss of anything important. I am sure that it can be improved in this r= espect using your specific observations as a guide. E6: I will use one of your suggested alternatives in place of "fidelity"...= the original intent of that word here was something like "the most exact re= production of the SMIv2 datatype possible with XSD". E7: "most direct" in R6 means the choice among the W3C defined XSD datatype= s that most closely matches the SMIv2 datatype, with only the smallest set = of XSD "restriction" required (if any) to provide "fidelity" (word to chang= e) to the SMIv2 datatype. E8: I don't find the phrase "no comments included" in the I-D, so I'm not s= ure how to respond to this exactly. However, perhaps you are misreading (w= hich would be my fault) the purpose of the requirements listed in Sec. 3: = They are requirements applied to the selection of XSD datatypes in this doc= ument only. The output produced (in either direction) is intended for cons= umption at the machine-to-machine level. When brought up to the level of h= uman users via management applications, the application may do whatever it = deems best in terms of XML (or other) output. The XSDMI "standard" will ha= ve done its job at a lower layer...i.e., ensuring that the raw SNMP data (o= r the SMIv2 datatype for pure data modeling applications) was represented c= orrectly at the protocol level. Even at the "raw data" level, an XML docum= ent produced and validated against this XSD could definitely include whatev= er comments the application creating the document deemed useful. Only the = datatypes and corresponding data values are addressed by this I-D (RFC). E9: Will do. E10: Will replace "faithful" to a term corresponding with the change to be = made per E6. E11: Will do. E12: Will do. Thanks again, Dan, and please let me know if any of the above responses are= unacceptable to you or could be further improved. Cheers, BobN -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Romascanu, Dan (Dan) Sent: Tuesday, June 16, 2009 7:26 AM To: opsawg@ietf.org Subject: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.tx= t Please find below the AD review for draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt. I believe that this document is mature enough to be sent to IETF Last Call. Unless there are any last minute comments I plan to send it to IETF Last Call by tomorrow.=20 The requirements below are dived into Technical and Editorial. Please consider them together with the other Last Call comments. T1. I am not sure that I understand requirement R2 in Section 3. It does not look like it imposes any requirement for the mapping. It is sufficient I think that we dully state that version SMIv2 is the version that is supported, and that any SMIv1 MIB module should be first translated into SMIv2. Maybe this is actually the intention, but this is not a requirement on the mapping.=20 E1. Running idnits results in the following warning:=20 =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." E2. According to RFC 5377 he Section 4 'code' will need to include a full version of the full BSD license or a statement agreed by the IETF Trust. The exact formulation of the statement is still in discussions, please follow the latest instructions available at http://trustee.ietf.org/license-info/ E3. Section 1 - s/legacy MIBs/legacy MIB modules/ E4. same - what does 'with attendant improvements' mean?=20 E5. same - it looks to me like some paragraphs are redundant and this section can be shortened. For example the paragraphs starting with 'The objective of this memo ...' and 'Having such a standard mapping ...' do not seem to bring any new information, they just say what was already said earlier in the same section. E6. same - 'The goal of fidelity ...' I am not sure that 'fidelity' is the right term - maybe 'consistency' or 'accurate translation' or 'accurate mapping' E7. Section 3, R6 - it is not clear to me what 'the most direct' means E8. same, R7 - again 'the most direct'. Also, I am not sure that saying 'no comments included' is a requirement. In many cases comments are useful and not superfluous 'decoration' E9. Section 5 - It would be good to include the exact reference to W3C XSD in the text E10. Section 5.1 - 'faithful' does not sound like the right term E11. Section 5.4 - although trivial for people familiar with SMI it may be helpful for some to explain why only IPv4 addresses are described in the document E12. Section 5.5 - It would be better rather then use a tutorial as a reference to refer to the standard directly for ASN.1 / BER Encoding. Reference [4] in RFC 2578 seems to be the right one.=20 Thanks and Regards, Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From ietfdbh@comcast.net Tue Jun 16 15:17:44 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8550328C1C3 for ; Tue, 16 Jun 2009 15:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 UNBmtImpkvfb for ; Tue, 16 Jun 2009 15:17:43 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id C374F28C123 for ; Tue, 16 Jun 2009 15:17:42 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 4mGh1c0080xGWP854mHuEi; Tue, 16 Jun 2009 22:17:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 4mHu1c0080UQ6dC3YmHuHA; Tue, 16 Jun 2009 22:17:54 +0000 From: "David Harrington" To: "'Natale, Bob'" , "'Romascanu, Dan \(Dan\)'" References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> Date: Tue, 16 Jun 2009 18:17:53 -0400 Message-ID: <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnudTEF2BuejjucSsWXt/SeycFI1wALvl8gAAqXHCA= Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 22:17:44 -0000 Hi, Personally, I think fidelity and faithful are the right words. >From Merriam-Webstre Dictionary: 1 a: the quality or state of being faithful b: accuracy in details : exactness 2: the degree to which an electronic device (as a record player, radio, or television) accurately reproduces its effect (as sound or picture) I think that Bob could state how this word was used to describe "the most exact reproduction of the SMIv2 datatype possible with XSD". He could also quote from the Merriam-Webster definition. "most direct" also says ""the most exact reproduction of the SMIv2 datatype possible with XSD" Of course, you could use exactness: 1 : exhibiting or marked by strict, particular, and complete accordance with fact or a standard 2 : marked by thorough consideration or minute measurement of small factual details #1 applies when you can do an exact translation, and #2 applies when you need to find the "most direct" almost-equivalent. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Natale, Bob > Sent: Tuesday, June 16, 2009 2:15 PM > To: Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] AD Review > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > > Hi Dan, > > Thanks for the comments and for moving the IETF process forward. > > Concerning your comments: > > T1: Yes, that is the intent of the R2: An SMIv1 MIB module > must be converted to SMIv2 (insofar as datatypes are > concerned) in accordance with RFC 3584 *prior to mapping to > XSD as specified in this I-D* (or eventual RFC). Perhaps I > should make that last part explicit in the wording of R2...? > > E1: I examined the idnits warning carefully at the time and > decided that the answer to its question "Should you add the > disclaimer?" was no, because it did not seem necessary per > the terms of the warning. Do you feel that was the wrong conclusion? > > E2: Reading RFC 5377 gives me a headache, literally, and > quickly. By time I got through the end of its Sec. 4.3, it > seemed to me that it was saying that the IETF Trustees > "should define" some kind of text to include for XSDs and > such. So, I then reviewed the text of > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf > (much bigger headache now) and it seems to me that it says > that the BSD license grant for the XSD "code" is implicitly > granted by virtue of the "Copyright Notice" in the I-D (RFC) > -- and that authors would have to do something concrete > (insert other text) to explicitly apply some other license > grant (or usage restrictions). Do you read that policy differently? > > E3: Will apply your change. > > E4: "attendant improvements" means "expected corresponding > improvements from more unified management" (or words to that > effect)...the predicate here is that technology that helps to > eliminate the need for discrete operations across multiple > management layers/technologies to complete a task is likely > to also result in overall faster operations and overall fewer > errors in operations. > > E5: You are probably right. I will take a look at how to > reduce the text w/o loss of anything important. I am sure > that it can be improved in this respect using your specific > observations as a guide. > > E6: I will use one of your suggested alternatives in place of > "fidelity"...the original intent of that word here was > something like "the most exact reproduction of the SMIv2 > datatype possible with XSD". > > E7: "most direct" in R6 means the choice among the W3C > defined XSD datatypes that most closely matches the SMIv2 > datatype, with only the smallest set of XSD "restriction" > required (if any) to provide "fidelity" (word to change) to > the SMIv2 datatype. > > E8: I don't find the phrase "no comments included" in the > I-D, so I'm not sure how to respond to this exactly. > However, perhaps you are misreading (which would be my fault) > the purpose of the requirements listed in Sec. 3: They are > requirements applied to the selection of XSD datatypes in > this document only. The output produced (in either > direction) is intended for consumption at the > machine-to-machine level. When brought up to the level of > human users via management applications, the application may > do whatever it deems best in terms of XML (or other) output. > The XSDMI "standard" will have done its job at a lower > layer...i.e., ensuring that the raw SNMP data (or the SMIv2 > datatype for pure data modeling applications) was represented > correctly at the protocol level. Even at the "raw data" > level, an XML document produced and validated against this > XSD could definitely include whatever comments the > application creating the document deemed useful. Only the > datatypes and c > orresponding data values are addressed by this I-D (RFC). > > E9: Will do. > > E10: Will replace "faithful" to a term corresponding with the > change to be made per E6. > > E11: Will do. > > E12: Will do. > > Thanks again, Dan, and please let me know if any of the above > responses are unacceptable to you or could be further improved. > > Cheers, > BobN > > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, June 16, 2009 7:26 AM > To: opsawg@ietf.org > Subject: [OPSAWG] AD Review of > draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > > Please find below the AD review for > draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt. I believe that this > document is mature enough to be sent to IETF Last Call. > Unless there are > any last minute comments I plan to send it to IETF Last Call by > tomorrow. > > The requirements below are dived into Technical and Editorial. Please > consider them together with the other Last Call comments. > > T1. I am not sure that I understand requirement R2 in Section > 3. It does > not look like it imposes any requirement for the mapping. It is > sufficient I think that we dully state that version SMIv2 is > the version > that is supported, and that any SMIv1 MIB module should be first > translated into SMIv2. Maybe this is actually the intention, > but this is > not a requirement on the mapping. > > > E1. Running idnits results in the following warning: > > == The document seems to lack a disclaimer for pre-RFC5378 work, but > was > first submitted before 10 November 2008. Should you add the > disclaimer? > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.). > > trust-12-feb-2009 Section 6.c.iii text: > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available > before November > 10, 2008. The person(s) controlling the copyright in > some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF > Standards Process. > > Without obtaining an adequate license from the person(s) > controlling the copyright in such materials, this > document may not > be modified outside the IETF Standards Process, and derivative > works of it may not be created outside the IETF > Standards Process, > except to format it for publication as an RFC or to translate it > into languages other than English." > > E2. According to RFC 5377 he Section 4 'code' will need to include a > full version of the full BSD license or a statement agreed by the IETF > Trust. The exact formulation of the statement is still in discussions, > please follow the latest instructions available at > http://trustee.ietf.org/license-info/ > > E3. Section 1 - s/legacy MIBs/legacy MIB modules/ > > E4. same - what does 'with attendant improvements' mean? > > E5. same - it looks to me like some paragraphs are redundant and this > section can be shortened. For example the paragraphs starting > with 'The > objective of this memo ...' and 'Having such a standard > mapping ...' do > not seem to bring any new information, they just say what was already > said earlier in the same section. > > E6. same - 'The goal of fidelity ...' I am not sure that 'fidelity' is > the right term - maybe 'consistency' or 'accurate translation' or > 'accurate mapping' > > E7. Section 3, R6 - it is not clear to me what 'the most direct' means > > E8. same, R7 - again 'the most direct'. Also, I am not sure > that saying > 'no comments included' is a requirement. In many cases comments are > useful and not superfluous 'decoration' > > E9. Section 5 - It would be good to include the exact > reference to W3C > XSD in the text > > E10. Section 5.1 - 'faithful' does not sound like the right term > > E11. Section 5.4 - although trivial for people familiar with > SMI it may > be helpful for some to explain why only IPv4 addresses are > described in > the document > > E12. Section 5.5 - It would be better rather then use a tutorial as a > reference to refer to the standard directly for ASN.1 / BER Encoding. > Reference [4] in RFC 2578 seems to be the right one. > > Thanks and Regards, > > Dan > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From j.schoenwaelder@jacobs-university.de Tue Jun 16 21:41:26 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7A23A68F4 for ; Tue, 16 Jun 2009 21:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.022, 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 qxALN42pF5uK for ; Tue, 16 Jun 2009 21:41:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E89F03A68ED for ; Tue, 16 Jun 2009 21:41:24 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 982D7C0014; Wed, 17 Jun 2009 06:41:35 +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 k02nIjfeKQmd; Wed, 17 Jun 2009 06:41:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1282C000F; Wed, 17 Jun 2009 06:41:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4C44B44EC8; Wed, 17 Jun 2009 06:41:32 +0200 (CEST) Date: Wed, 17 Jun 2009 06:41:32 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090617044132.GB8119@elstar.local> Mail-Followup-To: David Harrington , "'Natale, Bob'" , "'Romascanu, Dan (Dan)'" , "opsawg@ietf.org" References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "'Natale, Bob'" , "opsawg@ietf.org" Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:41:26 -0000 On Wed, Jun 17, 2009 at 12:17:53AM +0200, David Harrington wrote: > Personally, I think fidelity and faithful are the right words. > > From Merriam-Webstre Dictionary: > 1 a: the quality or state of being faithful b: accuracy in details : > exactness > 2: the degree to which an electronic device (as a record player, > radio, or television) accurately reproduces its effect (as sound or > picture) > > I think that Bob could state how this word was used to describe "the > most exact reproduction of the SMIv2 datatype possible with XSD". He > could also quote from the Merriam-Webster definition. > > "most direct" also says ""the most exact reproduction of the SMIv2 > datatype possible with XSD" > > Of course, you could use exactness: > 1 : exhibiting or marked by strict, particular, and complete > accordance with fact or a standard > 2 : marked by thorough consideration or minute measurement of small > factual details > > #1 applies when you can do an exact translation, and #2 applies when > you need to find the "most direct" almost-equivalent. Well, I could easily claim that the "most exact" or "most direct" or "faithful" translation of OCTET STRING (SIZE(4)) would be a hexBinary of the same length. Still, we translate IpAddress into a textual string containing a dotted number representation of the 4 octet value. I am not questioning this translation of IpAddress here - but I do share Dan's concerns about a marketing like language that claims that this translation is the "most exact" or "most direct" or "as faithful as possible" translation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From RNATALE@mitre.org Tue Jun 16 23:49:06 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D4543A692A for ; Tue, 16 Jun 2009 23:49:06 -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 O3s-VLEbH9wZ for ; Tue, 16 Jun 2009 23:49:05 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 373F828C18B for ; Tue, 16 Jun 2009 23:48:35 -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 n5H6mdM1023417 for ; Wed, 17 Jun 2009 02:48:40 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n5H6mdTk023414; Wed, 17 Jun 2009 02:48:39 -0400 Received: from IMCMBX2.MITRE.ORG ([129.83.29.205]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 17 Jun 2009 02:48:39 -0400 From: "Natale, Bob" To: Juergen Schoenwaelder , David Harrington Date: Wed, 17 Jun 2009 02:48:37 -0400 Thread-Topic: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnvBebEnsnqNVVzRUS4yidQ3JO5jwAD3RsA Message-ID: <17969D855F28964C88D177D45B6CDF11021A2547DD@IMCMBX2.MITRE.ORG> References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> <20090617044132.GB8119@elstar.local> In-Reply-To: <20090617044132.GB8119@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 06:49:06 -0000 Hi Juergen, You were extremely helpful in getting to the correct XSD representation of = IpAddress, so I hate to respond critically to your comment below...but I fe= el I must on two counts: 1. The requirements list for the selection of mappings also says this: - - - - - R4. The XSD datatype specified for a given SMI datatype MUST represent any special encoding rules associated with that SMI datatype. R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype. - - - - - So, the selected mappings for IpAddress and ObjectIdentifier go to "string"= to enable the proper restrictions on values in a reasonable way. 2. I believe that tossing "marketing" into the ring is either a red herring= or a low blow or both (nothing like getting smacked below the belt with a = red herring :). I personally consider it a worthy engineering goal when do= ing coding translations to be as faithful (in the sense of fidelity to the = original) and direct (in the sense of the minimum necessary "extras" to ach= ieve the true meaning of the original. It's reasonable to suggest more acc= urate synonyms, but the objective is engineering quality, regardless. Man, this is a tough place to complete a simple task. :( Or, maybe I'm just too sensitive and/or in too much of a rush...after all, = what's a couple of years for what should be a straightforward mapping of a = few datatypes...? Cheers, BobN -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, June 17, 2009 12:42 AM To: David Harrington Cc: Natale, Bob; 'Romascanu, Dan (Dan)'; opsawg@ietf.org Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05= .txt On Wed, Jun 17, 2009 at 12:17:53AM +0200, David Harrington wrote: =20 > Personally, I think fidelity and faithful are the right words. >=20 > From Merriam-Webstre Dictionary: > 1 a: the quality or state of being faithful b: accuracy in details : > exactness > 2: the degree to which an electronic device (as a record player, > radio, or television) accurately reproduces its effect (as sound or > picture)=20 >=20 > I think that Bob could state how this word was used to describe "the > most exact reproduction of the SMIv2 datatype possible with XSD". He > could also quote from the Merriam-Webster definition. >=20 > "most direct" also says ""the most exact reproduction of the SMIv2 > datatype possible with XSD" >=20 > Of course, you could use exactness: > 1 : exhibiting or marked by strict, particular, and complete > accordance with fact or a standard=20 > 2 : marked by thorough consideration or minute measurement of small > factual details=20 >=20 > #1 applies when you can do an exact translation, and #2 applies when > you need to find the "most direct" almost-equivalent. Well, I could easily claim that the "most exact" or "most direct" or "faithful" translation of OCTET STRING (SIZE(4)) would be a hexBinary of the same length. Still, we translate IpAddress into a textual string containing a dotted number representation of the 4 octet value. I am not questioning this translation of IpAddress here - but I do share Dan's concerns about a marketing like language that claims that this translation is the "most exact" or "most direct" or "as faithful as possible" translation. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 17 00:50:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBA43A6C73 for ; Wed, 17 Jun 2009 00:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 qtg23pLUVuSf for ; Wed, 17 Jun 2009 00:50:27 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id B4A8F3A692A for ; Wed, 17 Jun 2009 00:50:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,234,1243828800"; d="scan'208";a="164525308" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 17 Jun 2009 03:50:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2009 03:50:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 09:50:25 +0200 Message-ID: In-Reply-To: <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnudTEF2BuejjucSsWXt/SeycFI1wALvl8gAAqXHCAAFDeIUA== References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Natale, Bob" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:50:28 -0000 I trust your native English speaker skills :-)=20 I believe that a somehow more verbose definition could help.=20 Dan =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, June 17, 2009 1:18 AM > To: 'Natale, Bob'; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] AD Review=20 > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt >=20 > Hi, >=20 > Personally, I think fidelity and faithful are the right words. >=20 > From Merriam-Webstre Dictionary: > 1 a: the quality or state of being faithful b: accuracy in details : > exactness > 2: the degree to which an electronic device (as a record=20 > player, radio, or television) accurately reproduces its=20 > effect (as sound or > picture)=20 >=20 > I think that Bob could state how this word was used to=20 > describe "the most exact reproduction of the SMIv2 datatype=20 > possible with XSD". He could also quote from the=20 > Merriam-Webster definition. >=20 > "most direct" also says ""the most exact reproduction of the=20 > SMIv2 datatype possible with XSD" >=20 > Of course, you could use exactness: > 1 : exhibiting or marked by strict, particular, and complete=20 > accordance with fact or a standard > 2 : marked by thorough consideration or minute measurement of=20 > small factual details=20 >=20 > #1 applies when you can do an exact translation, and #2=20 > applies when you need to find the "most direct" almost-equivalent. >=20 > dbh >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of Natale, Bob > > Sent: Tuesday, June 16, 2009 2:15 PM > > To: Romascanu, Dan (Dan) > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] AD Review > > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > >=20 > > Hi Dan, > >=20 > > Thanks for the comments and for moving the IETF process forward. > >=20 > > Concerning your comments: > >=20 > > T1: Yes, that is the intent of the R2: An SMIv1 MIB module must be=20 > > converted to SMIv2 (insofar as datatypes are > > concerned) in accordance with RFC 3584 *prior to mapping to XSD as=20 > > specified in this I-D* (or eventual RFC). Perhaps I should=20 > make that=20 > > last part explicit in the wording of R2...? > >=20 > > E1: I examined the idnits warning carefully at the time and decided=20 > > that the answer to its question "Should you add the=20 > disclaimer?" was=20 > > no, because it did not seem necessary per the terms of the=20 > warning. =20 > > Do you feel that was the wrong > conclusion? > >=20 > > E2: Reading RFC 5377 gives me a headache, literally, and=20 > quickly. By=20 > > time I got through the end of its Sec. 4.3, it seemed to me that it=20 > > was saying that the IETF Trustees "should define" some kind=20 > of text to=20 > > include for XSDs and such. So, I then reviewed the text of=20 > > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf > > (much bigger headache now) and it seems to me that it says that the=20 > > BSD license grant for the XSD "code" is implicitly granted=20 > by virtue=20 > > of the "Copyright Notice" in the I-D (RFC) > > -- and that authors would have to do something concrete=20 > (insert other=20 > > text) to explicitly apply some other license grant (or usage=20 > > restrictions). Do you read that policy differently? > >=20 > > E3: Will apply your change. > >=20 > > E4: "attendant improvements" means "expected corresponding=20 > > improvements from more unified management" (or words to that=20 > > effect)...the predicate here is that technology that helps to=20 > > eliminate the need for discrete operations across multiple=20 > management=20 > > layers/technologies to complete a task is likely to also result in=20 > > overall faster operations and overall fewer errors in operations. > >=20 > > E5: You are probably right. I will take a look at how to=20 > reduce the=20 > > text w/o loss of anything important. I am sure that it can be=20 > > improved in this respect using your specific observations=20 > as a guide. > >=20 > > E6: I will use one of your suggested alternatives in place of=20 > > "fidelity"...the original intent of that word here was=20 > something like=20 > > "the most exact reproduction of the SMIv2 datatype possible=20 > with XSD". > >=20 > > E7: "most direct" in R6 means the choice among the W3C defined XSD=20 > > datatypes that most closely matches the SMIv2 datatype,=20 > with only the=20 > > smallest set of XSD "restriction" > > required (if any) to provide "fidelity" (word to change) to=20 > the SMIv2=20 > > datatype. > >=20 > > E8: I don't find the phrase "no comments included" in the=20 > I-D, so I'm=20 > > not sure how to respond to this exactly. > > However, perhaps you are misreading (which would be my fault) the=20 > > purpose of the requirements listed in Sec. 3: They are=20 > requirements=20 > > applied to the selection of XSD datatypes in this document=20 > only. The=20 > > output produced (in either > > direction) is intended for consumption at the machine-to-machine=20 > > level. When brought up to the level of human users via management=20 > > applications, the application may do whatever it deems best=20 > in terms=20 > > of XML (or other) output. > > The XSDMI "standard" will have done its job at a lower=20 > layer...i.e.,=20 > > ensuring that the raw SNMP data (or the SMIv2 datatype for=20 > pure data=20 > > modeling applications) was represented correctly at the protocol=20 > > level. Even at the "raw data" > > level, an XML document produced and validated against this=20 > XSD could=20 > > definitely include whatever comments the application creating the=20 > > document deemed useful. Only the datatypes and c =20 > orresponding data=20 > > values are addressed by this I-D (RFC). > >=20 > > E9: Will do. > >=20 > > E10: Will replace "faithful" to a term corresponding with=20 > the change=20 > > to be made per E6. > >=20 > > E11: Will do. > >=20 > > E12: Will do. > >=20 > > Thanks again, Dan, and please let me know if any of the above=20 > > responses are unacceptable to you or could be further improved. > >=20 > > Cheers, > > BobN > >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Tuesday, June 16, 2009 7:26 AM > > To: opsawg@ietf.org > > Subject: [OPSAWG] AD Review of > > draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > >=20 > > Please find below the AD review for > > draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt. I believe that this=20 > > document is mature enough to be sent to IETF Last Call. > > Unless there are > > any last minute comments I plan to send it to IETF Last Call by=20 > > tomorrow. > >=20 > > The requirements below are dived into Technical and Editorial. > Please > > consider them together with the other Last Call comments. > >=20 > > T1. I am not sure that I understand requirement R2 in Section 3. It=20 > > does not look like it imposes any requirement for the=20 > mapping. It is=20 > > sufficient I think that we dully state that version SMIv2 is the=20 > > version that is supported, and that any SMIv1 MIB module should be=20 > > first translated into SMIv2. Maybe this is actually the=20 > intention, but=20 > > this is not a requirement on the mapping. > >=20 > >=20 > > E1. Running idnits results in the following warning:=20 > >=20 > > =3D=3D The document seems to lack a disclaimer for pre-RFC5378 = work, > but > > was > > first submitted before 10 November 2008. Should you add the=20 > > disclaimer? > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.).=20 > >=20 > > trust-12-feb-2009 Section 6.c.iii text: > > "This document may contain material from IETF Documents or IETF > > Contributions published or made publicly available before=20 > > November > > 10, 2008. The person(s) controlling the copyright in some of=20 > > this > > material may not have granted the IETF Trust the right to > allow > > modifications of such material outside the IETF Standards=20 > > Process. > >=20 > > Without obtaining an adequate license from the person(s) > > controlling the copyright in such materials, this=20 > document may=20 > > not > > be modified outside the IETF Standards Process, and derivative > > works of it may not be created outside the IETF Standards=20 > > Process, > > except to format it for publication as an RFC or to translate > it > > into languages other than English." > >=20 > > E2. According to RFC 5377 he Section 4 'code' will need to=20 > include a=20 > > full version of the full BSD license or a statement agreed by the > IETF > > Trust. The exact formulation of the statement is still in > discussions, > > please follow the latest instructions available at=20 > > http://trustee.ietf.org/license-info/ > >=20 > > E3. Section 1 - s/legacy MIBs/legacy MIB modules/ > >=20 > > E4. same - what does 'with attendant improvements' mean?=20 > >=20 > > E5. same - it looks to me like some paragraphs are redundant and > this > > section can be shortened. For example the paragraphs starting with=20 > > 'The objective of this memo ...' and 'Having such a=20 > standard mapping=20 > > ...' do not seem to bring any new information, they just=20 > say what was > already > > said earlier in the same section. > >=20 > > E6. same - 'The goal of fidelity ...' I am not sure that 'fidelity' > is > > the right term - maybe 'consistency' or 'accurate translation' or=20 > > 'accurate mapping' > >=20 > > E7. Section 3, R6 - it is not clear to me what 'the most direct' > means > >=20 > > E8. same, R7 - again 'the most direct'. Also, I am not sure that=20 > > saying 'no comments included' is a requirement. In many=20 > cases comments=20 > > are useful and not superfluous 'decoration' > >=20 > > E9. Section 5 - It would be good to include the exact reference to=20 > > W3C XSD in the text > >=20 > > E10. Section 5.1 - 'faithful' does not sound like the right term > >=20 > > E11. Section 5.4 - although trivial for people familiar with SMI it=20 > > may be helpful for some to explain why only IPv4 addresses are=20 > > described in the document > >=20 > > E12. Section 5.5 - It would be better rather then use a tutorial as > a > > reference to refer to the standard directly for ASN.1 / BER > Encoding. > > Reference [4] in RFC 2578 seems to be the right one.=20 > >=20 > > Thanks and Regards, > >=20 > > Dan > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > >=20 >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Jun 17 03:54:22 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DADF73A69A4 for ; Wed, 17 Jun 2009 03:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EgYxb4Lp3REh for ; Wed, 17 Jun 2009 03:54:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EAFEB3A67A7 for ; Wed, 17 Jun 2009 03:54:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27F79C0039; Wed, 17 Jun 2009 12:54:33 +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 f1B-lj61YTN6; Wed, 17 Jun 2009 12:54: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 D1CEBC0035; Wed, 17 Jun 2009 12:54:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CE9C3B456F9; Wed, 17 Jun 2009 12:54:30 +0200 (CEST) Date: Wed, 17 Jun 2009 12:54:30 +0200 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20090617105430.GC9086@elstar.local> Mail-Followup-To: "Natale, Bob" , David Harrington , "'Romascanu, Dan (Dan)'" , "opsawg@ietf.org" References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <018d01c9eed0$4b356ad0$0600a8c0@china.huawei.com> <20090617044132.GB8119@elstar.local> <17969D855F28964C88D177D45B6CDF11021A2547DD@IMCMBX2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17969D855F28964C88D177D45B6CDF11021A2547DD@IMCMBX2.MITRE.ORG> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:54:22 -0000 On Wed, Jun 17, 2009 at 08:48:37AM +0200, Natale, Bob wrote: > You were extremely helpful in getting to the correct XSD > representation of IpAddress, so I hate to respond critically to your > comment below...but I feel I must on two counts: [...] It seems I did not get my message across too well. To make things simple, let me simply state that I support Dan's comments concerning the language in the requirements. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 17 04:02:42 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC0028C1D4 for ; Wed, 17 Jun 2009 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 r948KC5-jGG6 for ; Wed, 17 Jun 2009 04:02:41 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id E68AC3A6E2C for ; Wed, 17 Jun 2009 04:02:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,235,1243828800"; d="scan'208";a="164540164" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 17 Jun 2009 07:02:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Jun 2009 07:02:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 13:02:21 +0200 Message-ID: In-Reply-To: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnudTEF2BuejjucSsWXt/SeycFI1wALvl8gACTyVNA= References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> From: "Romascanu, Dan (Dan)" To: "Natale, Bob" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD Review of draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 11:02:42 -0000 Hi Bob, Thanks for the quick answer. See a few clarification answers back below. Please do not issue a revised I-D by now. I believe that this version is mature enough for last call.=20 Dan =20 > -----Original Message----- > From: Natale, Bob [mailto:RNATALE@mitre.org]=20 > Sent: Tuesday, June 16, 2009 9:15 PM > To: Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: RE: AD Review of=20 > draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt >=20 > Hi Dan, >=20 > Thanks for the comments and for moving the IETF process forward. >=20 > Concerning your comments: >=20 > T1: Yes, that is the intent of the R2: An SMIv1 MIB module=20 > must be converted to SMIv2 (insofar as datatypes are=20 > concerned) in accordance with RFC 3584 *prior to mapping to=20 > XSD as specified in this I-D* (or eventual RFC). Perhaps I=20 > should make that last part explicit in the wording of R2...? Yes.=20 >=20 > E1: I examined the idnits warning carefully at the time and=20 > decided that the answer to its question "Should you add the=20 > disclaimer?" was no, because it did not seem necessary per=20 > the terms of the warning. Do you feel that was the wrong conclusion? It's OK - I just wanted to make sure you are aware about the warning.=20 >=20 > E2: Reading RFC 5377 gives me a headache, literally, and=20 > quickly. By time I got through the end of its Sec. 4.3, it=20 > seemed to me that it was saying that the IETF Trustees=20 > "should define" some kind of text to include for XSDs and=20 > such. So, I then reviewed the text of=20 > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf=20 > (much bigger headache now) and it seems to me that it says=20 > that the BSD license grant for the XSD "code" is implicitly=20 > granted by virtue of the "Copyright Notice" in the I-D (RFC)=20 > -- and that authors would have to do something concrete=20 > (insert other text) to explicitly apply some other license=20 > grant (or usage restrictions). Do you read that policy differently? >=20 The RFC will need to include the full text of the full BSD license but exact location and the text to become part of the code is still being discussed. I suggest no edits by now as the exact text is not yet approved by the Trustees. > E8: I don't find the phrase "no comments included" in the=20 > I-D, so I'm not sure how to respond to this exactly. =20 > However, perhaps you are misreading (which would be my fault)=20 > the purpose of the requirements listed in Sec. 3: They are=20 > requirements applied to the selection of XSD datatypes in=20 > this document only. The output produced (in either=20 > direction) is intended for consumption at the=20 > machine-to-machine level. When brought up to the level of=20 > human users via management applications, the application may=20 > do whatever it deems best in terms of XML (or other) output. =20 > The XSDMI "standard" will have done its job at a lower=20 > layer...i.e., ensuring that the raw SNMP data (or the SMIv2=20 > datatype for pure data modeling applications) was represented=20 > correctly at the protocol level. Even at the "raw data"=20 > level, an XML document produced and validated against this=20 > XSD could definitely include whatever comments the=20 > application creating the document deemed useful. Only the=20 > datatypes and corresponding data values are addressed by this=20 > I-D (RFC). 'no comments included' are my words for what I was reading in R7. I understand now and accept your intention.=20 From cfinss@dial.pipex.com Wed Jun 17 07:06:17 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2843A6BD6 for ; Wed, 17 Jun 2009 07:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 Onh9sToSHJ6e for ; Wed, 17 Jun 2009 07:06:16 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 2F11828C0E3 for ; Wed, 17 Jun 2009 07:06:15 -0700 (PDT) X-Trace: 258166656/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.79/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.79 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAJ+VOEo+vGlP/2dsb2JhbACDKjyLa8VQCIQABQ X-IronPort-AV: E=Sophos;i="4.42,236,1243810800"; d="scan'208";a="258166656" X-IP-Direction: IN Received: from 1cust79.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.79]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Jun 2009 15:06:23 +0100 Message-ID: <000d01c9ef4c$3a958440$0601a8c0@allison> From: "tom.petch" To: "Natale, Bob" , "Romascanu, Dan \(Dan\)" References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> Date: Wed, 17 Jun 2009 14:46:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: opsawg@ietf.org Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:06:17 -0000 ----- Original Message ----- From: "Natale, Bob" To: "Romascanu, Dan (Dan)" Cc: Sent: Tuesday, June 16, 2009 8:14 PM Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > Hi Dan, > > Thanks for the comments and for moving the IETF process forward. > > Concerning your comments: > > > E1: I examined the idnits warning carefully at the time and decided that the answer to its question "Should you add the disclaimer?" was no, because it did not seem necessary per the terms of the warning. Do you feel that was the wrong conclusion? > I think that idnits is maintained by someone who does not approve of RFC5378:-( The aim should be for all future RFC to allow changes to be made outside the IETF process, with permission of the Trust, and that is what RFC5378 seeks to establish. The revised Note Well, which came into force on 10Nov2008 (even if many did not see it for days or months afterwards) requires us to grant those rights for our Contributions. But, the Sam Hartman problem, we are going to go on reusing material from before 10Nov2008 for years to come, for which no such grant has been made so idnits checks for a pre-10Nov2008 date and then tries to bully you into not granting RFC5378 rights. If you are solely responsible for the Contribution, or have got consent from any significant others, then of course you can and should grant RFC5378 rights and no disclaimer is needed. In which case, just ignore idnits. > E2: Reading RFC 5377 gives me a headache, literally, and quickly. By time I got through the end of its Sec. 4.3, it seemed to me that it was saying that the IETF Trustees "should define" some kind of text to include for XSDs and such. So, I then reviewed the text of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf (much bigger headache now) and it seems to me that it says that the BSD license grant for the XSD "code" is implicitly granted by virtue of the "Copyright Notice" in the I-D (RFC) -- and that authors would have to do something concrete (insert other text) to explicitly apply some other license grant (or usage restrictions). Do you read that policy differently? > I agree and see the text in the .pdf you cite but it is the whole text, starting with 'Copyright ...' and ending with '...POSSIBILITY OF SUCH DAMAGE' MIB modules (what else?) give an exemplar of how to do it, eg draft-ietf-isms-secshell. Tom Petch > > E3: Will apply your change. > > E4: "attendant improvements" means "expected corresponding improvements from more unified management" (or words to that effect)...the predicate here is that technology that helps to eliminate the need for discrete operations across multiple management layers/technologies to complete a task is likely to also result in overall faster operations and overall fewer errors in operations. > > E5: You are probably right. I will take a look at how to reduce the text w/o loss of anything important. I am sure that it can be improved in this respect using your specific observations as a guide. > > E6: I will use one of your suggested alternatives in place of "fidelity"...the original intent of that word here was something like "the most exact reproduction of the SMIv2 datatype possible with XSD". > > E7: "most direct" in R6 means the choice among the W3C defined XSD datatypes that most closely matches the SMIv2 datatype, with only the smallest set of XSD "restriction" required (if any) to provide "fidelity" (word to change) to the SMIv2 datatype. > > E8: I don't find the phrase "no comments included" in the I-D, so I'm not sure how to respond to this exactly. However, perhaps you are misreading (which would be my fault) the purpose of the requirements listed in Sec. 3: They are requirements applied to the selection of XSD datatypes in this document only. The output produced (in either direction) is intended for consumption at the machine-to-machine level. When brought up to the level of human users via management applications, the application may do whatever it deems best in terms of XML (or other) output. The XSDMI "standard" will have done its job at a lower layer...i.e., ensuring that the raw SNMP data (or the SMIv2 datatype for pure data modeling applications) was represented correctly at the protocol level. Even at the "raw data" level, an XML document produced and validated against this XSD could definitely include whatever comments the application creating the document deemed useful. Only the datatypes and c > orresponding data values are addressed by this I-D (RFC). > > E9: Will do. > > E10: Will replace "faithful" to a term corresponding with the change to be made per E6. > > E11: Will do. > > E12: Will do. > > Thanks again, Dan, and please let me know if any of the above responses are unacceptable to you or could be further improved. > > Cheers, > BobN > > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, June 16, 2009 7:26 AM > To: opsawg@ietf.org From wwwrun@core3.amsl.com Wed Jun 17 07:23:07 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7EB1F28C254; Wed, 17 Jun 2009 07:23:07 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090617142307.7EB1F28C254@core3.amsl.com> Date: Wed, 17 Jun 2009 07:23:07 -0700 (PDT) X-Mailman-Approved-At: Wed, 17 Jun 2009 07:27:06 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: draft-ietf-opsawg-smi-datatypes-in-xsd (Expressing SNMP SMI Datatypes in XML Schema Definition Language) to Proposed Standard X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 14:23:07 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Expressing SNMP SMI Datatypes in XML Schema Definition Language ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16924&rfc_flag=0 From dromasca@avaya.com Wed Jun 17 09:14:27 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931FE3A6BA8 for ; Wed, 17 Jun 2009 09:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_35=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 vBxfLgL152zK for ; Wed, 17 Jun 2009 09:14:26 -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 140553A6BB7 for ; Wed, 17 Jun 2009 09:14:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243828800"; d="scan'208";a="148823850" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2009 12:14:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2009 12:14:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 18:14:14 +0200 Message-ID: In-Reply-To: <000d01c9ef4c$3a958440$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt Thread-Index: AcnvVNIr7wM8OjIiTRCVhKnDitOzZAAEXI1Q References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <000d01c9ef4c$3a958440$0601a8c0@allison> From: "Romascanu, Dan (Dan)" To: "tom.petch" , "Natale, Bob" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD Review ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:14:27 -0000 I believe that this input should be addressed to the ipr wg with copy to the iesg and trustees@ietf.org.=20 Dan > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com]=20 > Sent: Wednesday, June 17, 2009 3:46 PM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] AD Review=20 > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt >=20 > ----- Original Message ----- > From: "Natale, Bob" > To: "Romascanu, Dan (Dan)" > Cc: > Sent: Tuesday, June 16, 2009 8:14 PM > Subject: Re: [OPSAWG] AD Review=20 > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt >=20 >=20 > > Hi Dan, > > > > Thanks for the comments and for moving the IETF process forward. > > > > Concerning your comments: > > > > > > > E1: I examined the idnits warning carefully at the time and decided=20 > > that the > answer to its question "Should you add the disclaimer?" was=20 > no, because it did not seem necessary per the terms of the=20 > warning. Do you feel that was the wrong conclusion? > > >=20 > I think that idnits is maintained by someone who does not=20 > approve of RFC5378:-( >=20 > The aim should be for all future RFC to allow changes to be=20 > made outside the IETF process, with permission of the Trust,=20 > and that is what RFC5378 seeks to establish. The revised=20 > Note Well, which came into force on 10Nov2008 (even if many=20 > did not see it for days or months afterwards) requires us to=20 > grant those rights for our Contributions. But, the Sam=20 > Hartman problem, we are going to go on reusing material from=20 > before 10Nov2008 for years to come, for which no such grant=20 > has been made so idnits checks for a pre-10Nov2008 date and=20 > then tries to bully you into not granting RFC5378 rights. If=20 > you are solely responsible for the Contribution, or have got=20 > consent from any significant others, then of course you can=20 > and should grant RFC5378 rights and no disclaimer is needed. =20 > In which case, just ignore idnits. >=20 > > E2: Reading RFC 5377 gives me a headache, literally, and=20 > quickly. By=20 > > time I > got through the end of its Sec. 4.3, it seemed to me that it=20 > was saying that the IETF Trustees "should define" some kind=20 > of text to include for XSDs and such. > So, I then reviewed the text of > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf=20 > (much bigger headache > now) and it seems to me that it says that the BSD license=20 > grant for the XSD "code" is implicitly granted by virtue of=20 > the "Copyright Notice" in the I-D > (RFC) -- and that authors would have to do something concrete=20 > (insert other > text) to explicitly apply some other license grant (or usage=20 > restrictions). Do you read that policy differently? > > >=20 > I agree and see the text in the .pdf you cite but it is the=20 > whole text, starting with 'Copyright ...' > and ending with > '...POSSIBILITY OF SUCH DAMAGE' >=20 > MIB modules (what else?) give an exemplar of how to do it, eg=20 > draft-ietf-isms-secshell. >=20 > Tom Petch > > > > E3: Will apply your change. > > > > E4: "attendant improvements" means "expected corresponding=20 > > improvements from > more unified management" (or words to that effect)...the=20 > predicate here is that technology that helps to eliminate the=20 > need for discrete operations across multiple management=20 > layers/technologies to complete a task is likely to also=20 > result in overall faster operations and overall fewer errors=20 > in operations. > > > > E5: You are probably right. I will take a look at how to=20 > reduce the=20 > > text w/o > loss of anything important. I am sure that it can be=20 > improved in this respect using your specific observations as a guide. > > > > E6: I will use one of your suggested alternatives in place of=20 > > "fidelity"...the > original intent of that word here was something like "the=20 > most exact reproduction of the SMIv2 datatype possible with XSD". > > > > E7: "most direct" in R6 means the choice among the W3C defined XSD=20 > > datatypes > that most closely matches the SMIv2 datatype, with only the=20 > smallest set of XSD "restriction" required (if any) to=20 > provide "fidelity" (word to change) to the > SMIv2 datatype. > > > > E8: I don't find the phrase "no comments included" in the=20 > I-D, so I'm=20 > > not sure > how to respond to this exactly. However, perhaps you are=20 > misreading (which would be my fault) the purpose of the=20 > requirements listed in Sec. 3: They are requirements applied=20 > to the selection of XSD datatypes in this document only. > The output produced (in either direction) is intended for=20 > consumption at the machine-to-machine level. When brought up=20 > to the level of human users via management applications, the=20 > application may do whatever it deems best in terms of XML (or=20 > other) output. The XSDMI "standard" will have done its job=20 > at a lower layer...i.e., ensuring that the raw SNMP data (or=20 > the SMIv2 datatype for pure data modeling applications) was=20 > represented correctly at the protocol level. Even at the=20 > "raw data" level, an XML document produced and validated=20 > against this XSD could definitely include whatever comments=20 > the application creating the document deemed useful. Only=20 > the datatypes and c > > orresponding data values are addressed by this I-D (RFC). > > > > E9: Will do. > > > > E10: Will replace "faithful" to a term corresponding with=20 > the change=20 > > to be > made per E6. > > > > E11: Will do. > > > > E12: Will do. > > > > Thanks again, Dan, and please let me know if any of the above=20 > > responses are > unacceptable to you or could be further improved. > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On=20 > > Behalf Of > Romascanu, Dan (Dan) > > Sent: Tuesday, June 16, 2009 7:26 AM > > To: opsawg@ietf.org >=20 >=20 From ietfdbh@comcast.net Wed Jun 17 09:32:05 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9EF528C2B1 for ; Wed, 17 Jun 2009 09:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, J_CHICKENPOX_35=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 AmZModW7BnkF for ; Wed, 17 Jun 2009 09:32:04 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 4171828C28B for ; Wed, 17 Jun 2009 09:32:04 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 50UJ1c00A1GhbT8594YEqn; Wed, 17 Jun 2009 16:32:14 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 54YD1c00S0UQ6dC3T4YD1L; Wed, 17 Jun 2009 16:32:14 +0000 From: "David Harrington" To: "'tom.petch'" , "'Natale, Bob'" , "'Romascanu, Dan \(Dan\)'" References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG> <000d01c9ef4c$3a958440$0601a8c0@allison> Date: Wed, 17 Jun 2009 12:32:12 -0400 Message-ID: <026701c9ef69$2b1300c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000d01c9ef4c$3a958440$0601a8c0@allison> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnvVNLR+PAteY7QTrGm9lVudZSOUgAB1NNQ Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD Reviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:32:05 -0000 Hi, This document is not a "greenfield" document. Unless Bob gets all the authors of SMIv2 and its predecessors and the earlier versions of this document to grant permission to apply the new rfc5378 copyright terms to this document, from my perspective, it is correct to use the pre5378 clause. I believe Bob will have a hard time reaching some of the authors, who have stopped participating in IETF and whose contact information is no longer valid. I think idnits correctly prompts authors to understand and verify that not using the pre5378 clause is the correct choice from a legal perspective. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of tom.petch > Sent: Wednesday, June 17, 2009 8:46 AM > To: Natale, Bob; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] AD > Reviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > > ----- Original Message ----- > From: "Natale, Bob" > To: "Romascanu, Dan (Dan)" > Cc: > Sent: Tuesday, June 16, 2009 8:14 PM > Subject: Re: [OPSAWG] AD Review > ofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt > > > > Hi Dan, > > > > Thanks for the comments and for moving the IETF process forward. > > > > Concerning your comments: > > > > > > > E1: I examined the idnits warning carefully at the time and > decided that the > answer to its question "Should you add the disclaimer?" was > no, because it did > not seem necessary per the terms of the warning. Do you feel > that was the wrong > conclusion? > > > > I think that idnits is maintained by someone who does not > approve of RFC5378:-( > > The aim should be for all future RFC to allow changes to be > made outside the > IETF process, with permission of the Trust, and that is what > RFC5378 seeks to > establish. The revised Note Well, which came into force on > 10Nov2008 (even if > many did not see it for days or months afterwards) requires > us to grant those > rights for our Contributions. But, the Sam Hartman problem, > we are going to go > on reusing material from before 10Nov2008 for years to come, > for which no such > grant has been made so idnits checks for a pre-10Nov2008 date > and then tries to > bully you into not granting RFC5378 rights. If you are > solely responsible for > the Contribution, or have got consent from any significant > others, then of > course you can and should grant RFC5378 rights and no > disclaimer is needed. In > which case, just ignore idnits. > > > E2: Reading RFC 5377 gives me a headache, literally, and > quickly. By time I > got through the end of its Sec. 4.3, it seemed to me that it > was saying that the > IETF Trustees "should define" some kind of text to include > for XSDs and such. > So, I then reviewed the text of > http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf > (much bigger headache > now) and it seems to me that it says that the BSD license > grant for the XSD > "code" is implicitly granted by virtue of the "Copyright > Notice" in the I-D > (RFC) -- and that authors would have to do something concrete > (insert other > text) to explicitly apply some other license grant (or usage > restrictions). Do > you read that policy differently? > > > > I agree and see the text in the .pdf you cite but it is the > whole text, starting > with 'Copyright ...' > and ending with > '...POSSIBILITY OF SUCH DAMAGE' > > MIB modules (what else?) give an exemplar of how to do it, eg > draft-ietf-isms-secshell. > > Tom Petch > > > > E3: Will apply your change. > > > > E4: "attendant improvements" means "expected corresponding > improvements from > more unified management" (or words to that effect)...the > predicate here is that > technology that helps to eliminate the need for discrete > operations across > multiple management layers/technologies to complete a task is > likely to also > result in overall faster operations and overall fewer errors > in operations. > > > > E5: You are probably right. I will take a look at how to > reduce the text w/o > loss of anything important. I am sure that it can be > improved in this respect > using your specific observations as a guide. > > > > E6: I will use one of your suggested alternatives in place > of "fidelity"...the > original intent of that word here was something like "the most exact > reproduction of the SMIv2 datatype possible with XSD". > > > > E7: "most direct" in R6 means the choice among the W3C > defined XSD datatypes > that most closely matches the SMIv2 datatype, with only the > smallest set of XSD > "restriction" required (if any) to provide "fidelity" (word > to change) to the > SMIv2 datatype. > > > > E8: I don't find the phrase "no comments included" in the > I-D, so I'm not sure > how to respond to this exactly. However, perhaps you are > misreading (which > would be my fault) the purpose of the requirements listed in > Sec. 3: They are > requirements applied to the selection of XSD datatypes in > this document only. > The output produced (in either direction) is intended for > consumption at the > machine-to-machine level. When brought up to the level of > human users via > management applications, the application may do whatever it > deems best in terms > of XML (or other) output. The XSDMI "standard" will have > done its job at a > lower layer...i.e., ensuring that the raw SNMP data (or the > SMIv2 datatype for > pure data modeling applications) was represented correctly at > the protocol > level. Even at the "raw data" level, an XML document > produced and validated > against this XSD could definitely include whatever comments > the application > creating the document deemed useful. Only the datatypes and c > > orresponding data values are addressed by this I-D (RFC). > > > > E9: Will do. > > > > E10: Will replace "faithful" to a term corresponding with > the change to be > made per E6. > > > > E11: Will do. > > > > E12: Will do. > > > > Thanks again, Dan, and please let me know if any of the > above responses are > unacceptable to you or could be further improved. > > > > Cheers, > > BobN > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of > Romascanu, Dan (Dan) > > Sent: Tuesday, June 16, 2009 7:26 AM > > To: opsawg@ietf.org > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From randy_presuhn@mindspring.com Wed Jun 17 09:42:25 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0135E3A6BA2 for ; Wed, 17 Jun 2009 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 JK4DKzFZq5hJ for ; Wed, 17 Jun 2009 09:42:24 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 166CF3A6E8D for ; Wed, 17 Jun 2009 09:42:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eeRNLXx4EcTiQplBNWw+jS/zSi7WgOnfnFLEGaBG7U4yFnB4XUJlZpYt9e/1Kea7; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.55.238] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGyDB-0000zO-C7 for opsawg@ietf.org; Wed, 17 Jun 2009 12:42:09 -0400 Message-ID: <006001c9ef6a$9edfaac0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <17969D855F28964C88D177D45B6CDF110218CADFC3@IMCMBX2.MITRE.ORG><000d01c9ef4c$3a958440$0601a8c0@allison> <026701c9ef69$2b1300c0$0600a8c0@china.huawei.com> Date: Wed, 17 Jun 2009 09:42:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf696869bdcdcce5164daea7ad25036e88e8e8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.238 Subject: Re: [OPSAWG] ADReviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:42:25 -0000 Hi - > From: "David Harrington" > To: "'tom.petch'" ; "'Natale, Bob'" ; "'Romascanu, Dan (Dan)'" > Cc: > Sent: Wednesday, June 17, 2009 9:32 AM > Subject: Re: [OPSAWG] ADReviewofdraft-ietf-opsawg-smi-datatypes-in-xsd-05.txt ... > This document is not a "greenfield" document. Unless Bob gets all the > authors of SMIv2 and its predecessors and the earlier versions of this > document to grant permission to apply the new rfc5378 copyright terms > to this document, from my perspective, it is correct to use the > pre5378 clause. Use of the pre5378 clause is only necessary if the document contains passages copied from the earlier work. (This is about *COPY*right, after all.) Merely referencing the ideas or names of data types isn't enough to make it necessary. Likewise, a properly credited quote from earlier work would also not trigger the need for the pre5378 clause. Randy From sob@harvard.edu Sun Jun 21 11:51:00 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E57E3A6D66 for ; Sun, 21 Jun 2009 11:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-1.179, BAYES_05=-1.11, SARE_MLH_Stock1=0.87] 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 WbZZo7vnZOs5 for ; Sun, 21 Jun 2009 11:51:00 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id E1EFB3A6B19 for ; Sun, 21 Jun 2009 11:50:59 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 1E7FD18DBDE1; Sun, 21 Jun 2009 14:51:14 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20090621185114.1E7FD18DBDE1@newdev.eecs.harvard.edu> Date: Sun, 21 Jun 2009 14:51:14 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] opsawg agenda items for Stockholm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 18:51:00 -0000 opsawg is currently scheduled to meet on wed morning 7/29 from 0900 to 1130 but I've not received any requests for agend a time (I asked for topics a month ago) so this is a 2nd reguest Scott From dromasca@avaya.com Sun Jun 21 22:58:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466463A6997 for ; Sun, 21 Jun 2009 22:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] 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 2YOHHE9Gqa5K for ; Sun, 21 Jun 2009 22:58:11 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 5BCF13A6784 for ; Sun, 21 Jun 2009 22:58:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,266,1243828800"; d="scan'208";a="164957433" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Jun 2009 01:58:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jun 2009 01:58:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 07:58:03 +0200 Message-ID: In-Reply-To: <20090621185114.1E7FD18DBDE1@newdev.eecs.harvard.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] opsawg agenda items for Stockholm thread-index: AcnyoUvzuXj9NHcVRKi5IlAccCG9EwAWdwSw References: <20090621185114.1E7FD18DBDE1@newdev.eecs.harvard.edu> From: "Romascanu, Dan (Dan)" To: "Scott O. Bradner" , Subject: Re: [OPSAWG] opsawg agenda items for Stockholm X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 05:58:12 -0000 Things on my list that I would expect the WG to discuss on the mail list and at the meeting in Stockholm=20 - draft-ietf-opsawg-operations-and-management - resolution of the last call comments, what happens next, document status?=20 - draft-andersson-mpls-tp-oam-def - WG item or drop? - same about draft-shimin-opsawg-snmp-errorstatusmib Dan > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Sunday, June 21, 2009 9:51 PM > To: opsawg@ietf.org > Subject: [OPSAWG] opsawg agenda items for Stockholm >=20 >=20 > opsawg is currently scheduled to meet on wed morning > 7/29 from 0900 to 1130=20 >=20 > but I've not received any requests for agend a time (I asked=20 > for topics a month ago) >=20 > so this is a 2nd reguest >=20 > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From root@core3.amsl.com Tue Jun 23 13:45:01 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 632583A6EF2; Tue, 23 Jun 2009 13:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090623204501.632583A6EF2@core3.amsl.com> Date: Tue, 23 Jun 2009 13:45:01 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action:draft-ietf-opsawg-operations-and-management-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions Author(s) : D. Harrington Filename : draft-ietf-opsawg-operations-and-management-08.txt Pages : 38 Date : 2009-06-23 New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents defining new protocols or protocol extensions, about covering aspects of operations and management that should be considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-08.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 Content-Type: Message/External-body; name="draft-ietf-opsawg-operations-and-management-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-23133345.I-D@ietf.org> --NextPart-- From ietfdbh@comcast.net Tue Jun 23 13:50:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253E63A6EF2 for ; Tue, 23 Jun 2009 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 H0h37Tt5ZWqE for ; Tue, 23 Jun 2009 13:50:48 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id E87CF28C2D8 for ; Tue, 23 Jun 2009 13:50:47 -0700 (PDT) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 7YhZ1c00D0xGWP857Yr4Ew; Tue, 23 Jun 2009 20:51:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 7Yr41c00B0UQ6dC3YYr4rv; Tue, 23 Jun 2009 20:51:04 +0000 From: "David Harrington" To: , "'IETF Discussion'" Date: Tue, 23 Jun 2009 16:51:03 -0400 Message-ID: <033e01c9f444$5279d780$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acn0RFHhCUPSVQBPRi2IYHNdMWe0hQ== Subject: [OPSAWG] LC summary for draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:50:49 -0000 Hi, Here is a summary of Last Call comments: 1) Cullen Jennings told chairs to pay attention; [dbh: no action required.] 2) Henning Schulzrinne concerned about slowing approvals, and applying to new protocols and extensions. [dbh: added text about the different needs for new protocols and extensions] 3) Bernard Aboba concerned that IETF should focus on making successful protocols, and Management Considerations may be an unnecessary requirement. [dbh: this document went to great lengths to say that it was NOT prescribing a Management Considerations requirement. sigh] Management support is seldom a show-stopper. Wants differentiation of need with new protocol versus existing protocols. [dbh: added text about the different needs for new protocols and extensions] 4) IANA - no problem [dbh: no action required.] 5) Miguel Garcia - GEN-ART + editorial [dbh: all comments fixed] 6) Sam Hartman - objects to BCP * It does not reflect practices across significant areas of the IETF interoperable mgmt not required for all protocols document focuses on networking devices; document should be scoped. [dbh: removed "primary" goal] [dbh: I added some text to "Designing for OPS and Management" in the Introduction that talks about the traditional approach of using MIB modules for networking devices, and that emerging technologies have caused a change to IETF technologies and atrategy, and management requirements.] * It does not provide clear, actionable guidelines normative requirements vs "might want to consider" [dbh: added text about "when appropriate," a data model might be used.] * It is not sufficiently clear to be understood outside the O&M area. fails to make distinctions (ops vs mgmt; config vs other mgmt) document organization and discussions jumbled. [dbh: removed the use of "operations model". It is unclear what the "model" part refers to. Changed text to discuss operations, and deployment, etc.] [dbh: I moved the counter discussion, which was probably the most jarring context change. I modified a few other places, but some specific suggestions for changes might be helpful. YMMV] [dbh: I removed discussions of data and control planes, and tried to make the discussion general enough to also include services.] 7) Eliot Lear - Informational, not BCP section 3.2 needs more applicability discussion [dbh: I added some text to "Designing for OPS and Management" in the Introduction that talks about the traditional approach of using MIB modules for networking devices, and that emerging technologies have caused a change to IETF technologies and atrategy, and management requirements.] [dbh: changed primary gola from interoperability to "the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (as part of total cost of operations) for that service."] 8) SM - does not scale well for BCP [dbh: no action required.] 9) Sam (in discussion with Dan) - this document does not indicate that a WG can decide "no management is fine". [dbh: section 4.2 is very clear on that point] 10) Eliot Lear - need applicability scope needs to be be smaller document [dbh: not something I think we can accomplish without a rewrite and consensus on whether to keep each detail. WG consensus was to not do a rewrite at this time.] 11) Eric Rosen - opposes BCP status [dbh: no action required.] 12) Randy Presuhn - Thinks document is important; prefers Informational to BCP. [dbh: no action required.] 13) Joel Halpern - discussion on OPS guidelines versus requirement [dbh: no action required.] 14) Andy Bierman - discussion of OPS guidelines versus requirement [dbh: no action required.] 15) Tom Petch - Thinks abstract should be changed. I do not understand his point well enough to take action, and, as he points out, the document says it is not trying to solve the problem he raises. [dbh: no action taken.] draft-ietf-opsawg-operations-and-management-08 has been posted. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From erosen@cisco.com Wed Jun 24 13:42:33 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F24D3A6806; Wed, 24 Jun 2009 13:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 4Y9mnwemgedN; Wed, 24 Jun 2009 13:42:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5C8A13A6FD4; Wed, 24 Jun 2009 13:42:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,285,1243814400"; d="scan'208";a="205200424" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2009 20:40:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5OKepcw019601; Wed, 24 Jun 2009 16:40:51 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5OKepbB001200; Wed, 24 Jun 2009 20:40:51 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n5OKeoJo011822; Wed, 24 Jun 2009 16:40:50 -0400 To: "David Harrington" In-reply-to: Your message of Tue, 23 Jun 2009 16:51:03 -0400. <033e01c9f444$5279d780$0600a8c0@china.huawei.com> Date: Wed, 24 Jun 2009 16:40:50 -0400 Message-ID: <11821.1245876050@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1030; t=1245876051; x=1246740051; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20LC=20summary=20for=20draft-ietf-opsawg- operations-and-management=20 |Sender:=20 |To:=20=22David=20Harrington=22=20; bh=hz4GVnQ9PY6Qg8FDOZK0rigAUNBist4zyilhXkI/IRI=; b=LHhRcZJoTa4hiQZRb+7z+NeSUMEs+HjZN3fEYM2lBiQ9x9G11kBL2hWTEy 5hK+5g85I9ko3pEqWI/Ab4BDDO+aX7Gb3DZf756QyC2WBtuO9rJl/H11tRsz podtd2/Eev; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: opsawg@ietf.org, 'IETF Discussion' Subject: Re: [OPSAWG] LC summary for draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 20:42:33 -0000 Looking through your summary of the LC comments, it appears that there is considerable sentiment to publish this document as Informational rather than as a BCP. Yet the new revision still says "Intended Status: BCP". > [dbh: this document went to great lengths to say that it was NOT > prescribing a Management Considerations requirement. sigh] If this document were to proceed as a BCP, the following text could be interpreted by an AD as license to require a "Management Considerations" section: "Any decision to make a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements." Since assigning responsibilities to the IESG is presumably out of scope of this document, why not shorten this sentence to: "This document avoids recommending any mandatory publication requirements" From sm@resistor.net Wed Jun 24 15:39:14 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104E13A6F26; Wed, 24 Jun 2009 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 SWrVnuPDSiUn; Wed, 24 Jun 2009 15:39:13 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 4E38F3A6F39; Wed, 24 Jun 2009 15:38:53 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Alpha0/8.14.4.Alpha0) with ESMTP id n5OMbaZu010673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2009 15:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1245883066; x=1245969466; bh=IrmBap2kxCtLeCQA/T3IA/TH73M33CWFLpPidOO5VNE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Oxp95rROqeFz/sqyinAJWINDFNt17W+q2i2it0CNQPbo15c1DVCDE26AB54RqFmYz 4BG0Jh7XD7C3yyalmDbuDiv4q1qLB3wTi5PB6zuys28N2IgVTT7EkmrnEhu94NxroP DMPa+11s6QHlRRmkvZnIscAI+HYPeVGWpZXv78Ug= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=GWY2I1lt7oiUZk2MIbyZBrjnVY87t8VkXG2/ue6beZu+MLw5Ol6hDCCMvbVfTiHCn 8YKxPXT/8YJ4HRj2b8daIIY0UqyzKcepVXCEBz5q1kRDuRu4D3l+kPJgs8US73FEFxy vMTcv0OktIimy4IQWryBiY9T8dtrSVCXHJuxLxc= Message-Id: <6.2.5.6.2.20090624144912.02a09fd8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 24 Jun 2009 15:35:04 -0700 To: David Harrington , IETF Discussion From: SM In-Reply-To: <033e01c9f444$5279d780$0600a8c0@china.huawei.com> References: <033e01c9f444$5279d780$0600a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 25 Jun 2009 01:56:03 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] LC summary for draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:39:14 -0000 Hi David, At 13:51 23-06-2009, David Harrington wrote: >3) Bernard Aboba concerned that IETF should focus on making successful >protocols, and Management Considerations may be an unnecessary >requirement. >[dbh: this document went to great lengths to say that it was NOT >prescribing a Management Considerations requirement. sigh] The problem is not about what your document is not prescribing. It is about how it may be used. In Section 1: "This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase." In an Informational document, guidelines provide guidance. In a BCP document, it can be read as "the IETF community agrees to adopt these guidelines". In Section 1.2: "This document does not impose a solution, or imply that a formal data model is needed, or imply that using a specific management protocol is mandatory." The catch is in the following sentence: "Any decision to make a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements." The IESG could come up with such a requirement for the IETF Stream if this document is published as a BCP. In Section 1.3: "The IESG policy to require working groups to write a MIB module to provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals." The insistence on BCP could be seen as a way to set the stage for that. At 13:40 24-06-2009, Eric Rosen wrote: >Since assigning responsibilities to the IESG is presumably out of scope of >this document, why not shorten this sentence to: > > "This document avoids recommending any mandatory publication > requirements" I suggest a slight change to the proposed sentence: This document does not recommend any mandatory publication requirements I also suggest publishing the document as Informational. Regards, -sm From dromasca@avaya.com Thu Jun 25 03:44:10 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6994A3A6A70 for ; Thu, 25 Jun 2009 03:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 nBJ2x5ZxeFVi for ; Thu, 25 Jun 2009 03:44:09 -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 96FD03A6A4C for ; Thu, 25 Jun 2009 03:43:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,290,1243828800"; d="scan'208";a="149545627" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jun 2009 06:43:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 25 Jun 2009 06:43:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 12:42:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review for draft-ietf-opsawg-syslog-snmp-03.txt and draft-ietf-opsawg-syslog-msg-mib-04.txt thread-index: Acn1gaf7QTsCrFIySyKRa6nEoHAtwQ== From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] AD review for draft-ietf-opsawg-syslog-snmp-03.txt and draft-ietf-opsawg-syslog-msg-mib-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 10:44:10 -0000 I believe that both documents are ready for IETF Last Call. If no other comments are being sent to the list I will send the two documents to IETF Last Call by Sunday 6/29.=20 Please consider the comments below together with the other IETF Last Call comments:=20 draft-ietf-opsawg-syslog-snmp-03.txt: 1. In section 2.1:=20 This document assumes that notifications are in the format defined in RFC 3416 [RFC3416]. Notifications in the SNMPv1 notification format must be translated as described in Section 3.1 of RFC 3584 [RFC3584]. I believe that the text here must use a 2119 MUST and be more clear that this translation MUST happen on the snmp-to-syslog translator to accommodate reception and translation of SNMPv1 traps=20 2. Sections 3.1 and 3.2 seem to impose requirements on the functionality and behavior of the snmp-to-syslog translator that are appropriate to be described with RFC 2119 capitalization.=20 3. Why is the BER encoding of the trap included in the usage example in Section 5? 4. id-nits complains about an obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) draft-ietf-opsawg-syslog-msg-mib-04.txt: 1. id-nits complain on a missing reference: 'RFC3412' is mentioned on line 664, but not defined 2. It would be nice to write 'SYSLOG to SNMP converter' in a manner consistent to the way 'snmp-to-syslog translator' is written in the companion I-D. BTW, is there any reason for calling one 'converter' and the other 'translator'?=20 3. Implementations of this MIB module may truncate the message part of the syslog message such that it fits into the size constraints imposed by the implementation environment - how does such truncation happen? Are all syslog messages on a given converter always truncated at the same value? Should not this be indicated by a MIB object?=20 4. Would not a counter of the number of received syslog messages be useful for a manager? 5. Security Considerations -Writing on syslogMsgEnableNotifications involves one more threat - preventing management applications that use SNMP from receiving real-time notifications about events carried in syslog messages.=20 Thanks and Regards, Dan From cfinss@dial.pipex.com Sat Jun 27 04:05:52 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325F83A6B34 for ; Sat, 27 Jun 2009 04:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_05=-1.11, URIBL_RHS_DOB=1.083] 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 lwcDLaZAg8jB for ; Sat, 27 Jun 2009 04:05:51 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 2E2593A67FD for ; Sat, 27 Jun 2009 04:05:51 -0700 (PDT) X-Trace: 116688027/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.44/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.44 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAPeZRUo+vGks/2dsb2JhbACDK1SLYr5PCYQEBYkA X-IronPort-AV: E=Sophos;i="4.42,300,1243810800"; d="scan'208";a="116688027" X-IP-Direction: IN Received: from 1cust44.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.44]) by smtp.pipex.tiscali.co.uk with SMTP; 27 Jun 2009 12:06:08 +0100 Message-ID: <004a01c9f70e$ac63e340$0601a8c0@allison> From: "tom.petch" To: , "Scott O. Bradner" References: <20090610120434.B64C71826A4C@newdev.eecs.harvard.edu> Date: Sat, 27 Jun 2009 11:43:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Subject: Re: [OPSAWG] draft-andersson-mpls-tp-oam-def-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 11:05:52 -0000 Useful as an I-D in this field might be, I would urge caution whenever the characters mpls-tp appear. There is another memo, draft-andersson-mpls-tp-process, which, although I find not easy to follow, describes a modification to the IETF process as and when the MEAD team decides it shall be so, on the grounds that this is an MPLS-TP document. I would not want this WG to take on anything involving mpls-tp without a cast-iron, inalienable guarantee from the MEAD team that they will have nothing more to do with it. I track the mpls-tp discussion list and would not want those discussions on any more lists:-) Tom Petch ----- Original Message ----- From: "Scott O. Bradner" To: Sent: Wednesday, June 10, 2009 2:04 PM Subject: [OPSAWG] draft-andersson-mpls-tp-oam-def-01.txt > > We had a presentation of this ID at a WG meeting a while back. > > At the time there seemed to be some interest in publishing a RFC > that would be a help to people trying to understand just what > the concept of OAM means in the IETF and other contexts - since > there is so much confusion and because it can be hard to hold > a conversation with somone coming from a different context. > > this is a call to see if you-all think that this ID > (draft-andersson-mpls-tp-oam-def-01.txt) whould be adopted > by the opsawg as a work item. > > Please comment on the list in the next two weeks (i.e., before > June 25th) > > Thanks > > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From dhc2@dcrocker.net Sat Jun 27 08:16:43 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80B528C163; Sat, 27 Jun 2009 08:16:43 -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 O80lFuElfWtz; Sat, 27 Jun 2009 08:16:42 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 3D9D33A6A3E; Sat, 27 Jun 2009 08:16:41 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-124-148-164.dsl.pltn13.pacbell.net [67.124.148.164]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n5RFGrIN027016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Jun 2009 08:16:59 -0700 Message-ID: <4A4637E5.5010703@dcrocker.net> Date: Sat, 27 Jun 2009 08:16:53 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: IETF Discussion References: <033e01c9f444$5279d780$0600a8c0@china.huawei.com> <6.2.5.6.2.20090624144912.02a09fd8@resistor.net> In-Reply-To: <6.2.5.6.2.20090624144912.02a09fd8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 27 Jun 2009 08:16:59 -0700 (PDT) X-Mailman-Approved-At: Sun, 28 Jun 2009 06:52:34 -0700 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] LC summary for draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 15:16:43 -0000 SM wrote: > In an Informational document, guidelines provide guidance. In a BCP > document, it can be read as "the IETF community agrees to adopt these > guidelines". In Section 1.2: > > "This document does not impose a solution, or imply that a formal data > model is needed, or imply that using a specific management protocol > is mandatory." > > The catch is in the following sentence: > > "Any decision to make a Management Considerations section a mandatory > publication requirement for IETF documents is the responsibility of > the IESG, or specific area directors, or working groups, and this > document avoids recommending any mandatory publication requirements." > > The IESG could come up with such a requirement for the IETF Stream if > this document is published as a BCP. In practical terms, the IESG could come up with that requirement whether this document is BCP or not. Language such as you quoted does not "enable" an IESG action; it merely reminds the reader where a particular authority rests. So the concern you raise is a non-sequitor. More importantly, what is the purpose of having a consensus process for a document that has no status reflecting a consensus, particularly when that document seeks to alter behavior? The term guidance means giving direction. That's not merely informative. It is, by definition, directive. The IETF's labels for documents that are directive are standards track and BCP. Normative labels (stds trk & bcp) are particularly helpful when the community needs to adjust its sense of priorities, to do things it probably should have doing all along, but hasn't. The danger of a normative label, for non-protocol documents, is that they can be taken as casting things into Procrustean concrete. This draft has language that is reasonable cautious of such over-application, although this does require the reader to pay attention to the words that are actually written in the document... If the job of this document were merely to provide a reference about some issues, Informational would make sense. But it has a more directive intent than that. It seeks to get specification writers to include considerations and material that has been notably lacking in IETF development work. That's not merely informational. It is, by definition, stating a really good -- probably even a Best -- current practice for developing specifications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From wwwrun@core3.amsl.com Mon Jun 29 08:25:57 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 598373A6A32; Mon, 29 Jun 2009 08:25:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090629152557.598373A6A32@core3.amsl.com> Date: Mon, 29 Jun 2009 08:25:57 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: draft-ietf-opsawg-syslog-msg-mib (Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications) to Proposed Standard X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:25:57 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18178&rfc_flag=0 From wwwrun@core3.amsl.com Mon Jun 29 08:26:27 2009 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 220263A6DEB; Mon, 29 Jun 2009 08:26:26 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090629152627.220263A6DEB@core3.amsl.com> Date: Mon, 29 Jun 2009 08:26:27 -0700 (PDT) Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: draft-ietf-opsawg-syslog-snmp (Mapping Simple Network X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:26:27 -0000 Management Protocol (SNMP) Notifications to SYSLOG Messages) to Proposed Standard The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18179&rfc_flag=0 From ietfdbh@comcast.net Mon Jun 29 14:21:30 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66163A6BE2 for ; Mon, 29 Jun 2009 14:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, SARE_OEM_OBFU=1] 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 m4-r3Q-f7FTH for ; Mon, 29 Jun 2009 14:21:29 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id F2E913A6B2B for ; Mon, 29 Jun 2009 14:21:28 -0700 (PDT) Received: from OMTA15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 9nHh1c0091swQuc55xMqqM; Mon, 29 Jun 2009 21:21:50 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA15.westchester.pa.mail.comcast.net with comcast id 9xNx1c00S0UQ6dC3bxNySa; Mon, 29 Jun 2009 21:22:58 +0000 From: "David Harrington" To: Date: Mon, 29 Jun 2009 17:21:48 -0400 Message-ID: <02e501c9f8ff$9ccefe90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acn4xiXoVV1CHRnOR8e0ftZK1aoekQACT6tQ Subject: Re: [OPSAWG] draft-richard-opsawg-cna-mib-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:21:30 -0000 Hi, I reviewed this document quickly. I have some concerns. 1) I think the title "Centralized Network Architecture" is misleading. This is not about an architecture for Centralized Networking. It is an architecture for centralized network management. 2) I think the term Centralized is misleading. This architecture is about distibuted management, handled through distributed configuration servers, that configure and monitor a set of "dumb devices", such as wireless access points. The server is central only to the set of local devices, not centralized in the network. 3) That said, I believe the CAPWAP model for locally-centralized configuration management could, and should, be extended to also work in wired networks. With the emergence of "dumb" devices like netbooks, which might connect via a wireless or wired interface, this method of locally-centralized configuration could be very useful. 4) I found the beginning of section 5 difficult to understand. It discusses the "SNMP based management model of centralized network architecures", and I am not sure I agree with such a characterization. An SNMP system can have multiple management applications interacting with multiple managed devices. They have an m:n relationship, not a 1:n relationship. I think the problem here is again the use of "centralized network architecture" terminology. 5) The description in section 5 is really about using SNMP to distribute configurations to distributed configuration servers, and then to use a CAPWAP-like protocol to actually pass the configuration from the distributed server to the CAPWAP-managed device. 6) SNMP has a long history, but has not been wildly successful as a configuration protocol, or a configuration distribution protocol. The IETF is moving away from the SNMP-and-MIB Management Framework, and moving toward an approach that permits multiple co-existing management protocols to be used for different purposes, including SNMP-and-MIB. Designing an SNMP-only approach to distribute configurations to support this CAPWAP-like distributed configuration approach might not be the best approach. - I recommend that this document clearly separate the AC-TP relationship from the configuration distribution mechanism. - I recommend the protocol distribution mechanism (and design objectives, etc.) be described in an information model. See RFC3444 for discussion of information models versus data models. - I recommend the document (or a supplementary document) could then show how SNMP and the MIB data model defined here could be used. In that way, this proposal could be supplemented, using other configuration protocols, such as Netconf, to provide configuration distribution to the AC. 7) This MIB module deliberately reuses existing MIB modules, and I applaud this. Hopefully when data models are developed for other configuration protocols, such as Netconf, care will be taken to reuse existing information models, such as those underlying the Interfaces MIB and associated MIB modules. 8) It is unclear whether this MIB module depends on an unchanging ifIndex, which has proven problematic in real world devices with hot-swap capabilities. IfAlias was developed to help address the lack of persistence of ifIndexes across reboots. The TP Profile and TP Virtual Interfaces solution should be looked at closely to ensure assumptions about interfaces have not become outdated assumptions. 9) COPS-PR and Netconf have both been designed explicitly to address configuration needs. Both found the need to have a configuration lock capability to prevent conflicts from multiple NM interfaces (and for this proposal, an SNMP lock would probably be needed to prevent two different SNMP managers from trying to change the configuration distributed to the AC at the same time.) 10) In section 7.3, it says "By combining the MIB modules,"; I think this should be "By querying both the CMA-MIB and ENTITY-MIB modules," 11) In section 8, part 2, I think there is an assumption that ifIndex values will be assigned in a range from 1..number of interfaces. I am not sure that assumption is valid. If I recall correctly, especially in response to hotswap capabilities, some vendors have used structured numbering, especially in chassis environments. For example, a vendor might use ifIndex 41 to indicate slot 4, interface 1. If slot 4 was hotswapped and the new blade had a different number of interfaces, only the ifIndexes of slot 4 would be impacted. 12) This document uses stations and termination points. I know this is normal terminology for 802.11 and CAPWAP, but I think it deserves more explanation in the terminology section. Since MIB modules are often distributed without the surrounding text, I think the description clauses also need to be clear about what the terminology means, especially in the TEXTUAL-CONVENTIONs. cnaTpSessions and cnaStationSessions have a rnage of 0..65535; why were these numbers chosen? Are these carry-overs from 802.11 limits? Can a wired AC support more TPs or stations? in cnaTpProfiletable, "An operator could change a TP's configuration by changing the values of parameters in the corresponding TP profile." I think this needs to be more explicit about how this happens. Just changing the value of an object does not seem sufficient to me. cnaTpProfileTpId says the tunnel protocol **should** contain the MAC address. If the tunnel does not contain the mac address, then this system doesn't work right? So shouldn't this be a MUST? cnaTpProfileRowStatus says the system should ask the operator to confirm the decision to delete the profile. SNMP has no support for such a confirmation step. I recommend you put this into an implementer's guidelines section of the document, not in the MIB itself. Why is it not a MUST to remove the related network access MIB objects? When is it acceptable to not delete such objects? cnaTpEntry says an operator can query TP status using identifier of a TP profile. Since you say this in the cnaTpEntry, I assume you mean you can GET a cnaTpEntry using an identifier of TP profile. I believe that is incorrect. SNMP knows how to GET an entry using the INDEX to this table, which is cnaTPId not cnaTpProfileId. cnaTpProfileTpModelNumber says it "Represents the model name of a TP." Then you should call it cnaTpProfileTpModelName. This is an SnmpAdminString, which is not necessarily a number. It also says the TP modle name reflects the number of PHY interfaces. You seem tp be greatly overloading this field and making unwarranted assumptions about its content, and what you can surmise from its content. cnaTpIpAddress Represents the IP address of a TP. Can a TP have a non-IP address? cnaTpState enumerations appear to be based on 802.11. " The information such as software version of a specific TP could be accessed through the" cnaTpPhyIndex. I believe that is incorrect, if you are using SNMP, which only provides access through the INDEX. SNMP does not have secondary or indirect indexes. Are you sayiong that cnaTpPhyIndex matches the INDEX of another table that contains siftware version? If so, then you need to be explicit about the other table. If you are going to provide pointers to other tables this way, you need to pay close attention to fate sharing. If the row with cnaTpPhyIndex=79 is deleted, than does the entry in another table with INDEX=79 need to be deleted to match? Or if the entry in another tbale with INDEX=79 is deleted, then must this row that points to that row need to be deleted? What happens if the row pointed to does not exist? What happens if the row pointed is deleted and then a new row with the same INEX is created? Now this row points to the wrong row in the other table. is the other tabel defined in a way that prevents reuse of a deleted index from happening? cnaInterfaceMappingIfId makes assumptions abotu hwo the numbering is done. Where is it required that the first interface is numbered the same on different TPs? Is that first number a 0 or a 1? Why can a vendor not choose to start numbering at 101 (to represent say, blade 1 interface 1)? cnaInterfaceMappingVirtualIfIndex Represents the index value that uniquely identifies a TP Virtual Interface. The interface identified by a particular value of this index is the same interface as identified by the same value of the ifIndex. While not usually a problem, you should recognize that contexts are an important part of instance identification in SNMP. If I query an SNMP agent for its interfaces table using one context, and I query the same SNMP agent for its interfaces table using a different context, I can get different interfaces tables. For example, a chassis with a single SNMP agent and multiple blades might send back different ifIndex lists depending on whether the context is "blade 1" or "blade 2" or "". When queried for "blade 1", the ifIndex list might be 1,2,3. When queried for "blade 2", it might return 1,2,3,4. When queried for the "" context, you might get 101, 102, 103, 201, 202, 203, 204. You need to be more careful with your assumptions. RFC3411 describes this in section 3.3.1. cnaStationAssociateTime "Represents the time when the station is associated with the network." Is that the same time as the station is associated with the TP specified in cnaStationAssociateTpId? is that the same time station is associated with the interface specified in cnaStationAssociateMappingIfId? What's a network? cnaTpEventsStatsRebootCount is only triggered by a crash, and not another type of reboot? Then why not call it Crash Count? cnaTpEventsStatsLinkFailureCount "Represents the number of times that a tunnel protocol connection with an AC has failed due to link failure." From whose prespective? the TP or the AC? If there is a filure connecting to the AC, then that happens at the TP, right? But the TP doesn't necessarily support MIB statistics; it is the AC that supports SNMP. So shouldn't the count be done by the AC? i.e., the AC should count the number of failures to connect to the TP. This problem seems to apply to all your counters. Are the notifications designed to be sent by the AC or the TP? I thought the TP did not support SNMP. I think you need to make this clearer. I think the security consideration should discuss the different security domains involved. The security chosen to secure the SNMP messages between an NMS application and the AC might be of a different strength, or even based on different users, than the CAPWAP-like protocol used between the AC and TPs. Using SNMPv3 might secure the sensitive information between the NMS and the AC, but the data might be totally unsecured between AC and TP. The security considerations doesn't really discuss the implications of exposing the stats table or the eventsstatstable. What about the othr objects in the MIB? How sensitive are they? *For those who might wonder, the authors work for H3C (aka Huawei-3Com), I officially work for Huawei USA, and am doing work for HuaweiSymantec. These are three different companies, and I have no Huawei-related interactios with the authors, only IETF-related interactions. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -----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, June 29, 2009 10:30 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-richard-opsawg-cna-mib-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Generic MIB for Centralized Network Architecture Author(s) : Y. Shi, J. Wang Filename : draft-richard-opsawg-cna-mib-00.txt Pages : 37 Date : 2009-06-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for a generic model to manage the centralized network architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-richard-opsawg-cna-mib-00.tx t 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.